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I.  REVIEW  OF  PROBLEM  AMD  APPROACH 

As  hardware  becomes  less  expensive,  It  Is  increasingly  appropriate  and 
important  to  put  greater  emphasis  on  reducing  the  cost  of  software.  It  is 
well  known  that  a  great  deal  of  the  cost  of  software  arises  in  debugging,  and 
particularly  in  debugging  small  changes  in  large  programs  during  the  process 
of  maintaining  them.  Moreover,  it  seems  clear  that  a  major  contributing 
factor  to  difficulties  of  this  kind  is  the  generally  poor  quality  of 
documentation  of  such  large  programs,  so  that  the  programmer  who  has  to  do  the 
maintenance  has  great  difficulty  in  determining  the  effects  of  changes  which 
he  makes  in  the  code.  It  Is  becoming  increasingly  clear  to  the  computer 
science  community  that  formal  program  specification  is  promising  as  a 
solution,  and  that  specialized  specification  languages  are  helpful  in 
expressing  such  program  specifications. 

The  goal  of  this  research  has  been  to  develop  a  formal  and  executable 
algebraic  specification  language  which  can  be  used  to  specify  a  variety  of 
application  programs,  such  as  database  systems,  compilers  and  interpreters  for 
programming  languages,  and  business  systems.  An  advantage  of  formality  in 
this  context  is  that  each  specification  has  a  unique  unambiguous  meaning,  so 
that  it  is  actually  meaningful  to  ask  whether  or  not  a  given  program  in  fact 
satisfies  a  given  specification.  An  advantage  of  executability  is  that  test 
cases  can  be  run  directly  on  the  specification,  to  examine  properties  of 
programs  before  they  are  written,  and  to  help  in  debugging  specifications. 

The  latter  is  important  because  large  specifications,  like  large  programs,  are 
usually  wrong  as  first  written. 

We  have  been  investigating  the  utility  of  a  number  of  potential  advantages  of 
the  algebraic  approach,  including  the  following: 

1.  Achievement  of  a  high  level  of  modularity  in  a  natural  way; 

2.  Achievement  of  a  high  level  of  abstraction  in  a  natural  way; 

3.  The  possibility  of  executing  test  cases; 

4.  User  definition  of  data  types  and  control  structures,  using  any 
desired  syntax,  including  pre-fix,  post- fix,  and  "mix- fix" 
operators,  as  well  as  coercions; 

5.  The  specification  of  error  and  exception  conditions,  as  well  as 

their  handling,  and  recovery;  -  *  .... 


ij 

6.  The  use  of  parameterized  abstract  modules  as  a  method  for 
structuring  specifications; 

7.  Algorithms  for  checking  consistency  and  other  desirable  properties 
of  specifications  (e.g.,  the  Knuth-Bendix  algorithm);  and 

8.  Provision  of  a  completely  rigorous  semantics  for  all  these 
features. 
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II.  PROGRESS 

This  section  describes  the  progress  which  we  have  made  on  this  project. 

1 .  Implementations 

J.  Tardo  has  provided  a  new  implementation  of  OBJ,  called  0BJT20,  which  fixes 
most  of  the  bugs  discovered  in  his  previous  OBJT  implementation.  Both  OBJT 
and  0BJT20  are  currently  running  on  SRI’s  DEC-20  system,  but  we  will  soon 
retire  the  old  OBJT,  and  rename  the  new  0BJT20  to  OBJT.  The  bugs  found  in 
OBJT  are  documented  in  a  memorandum,  reproduced  in  Appendix  A  here,  based  on 
our  extensive  experience  using  OBJT. 

The  new  0BJT20  implementation  runs  faster,  takes  less  space,  permits  lower 
case  letters,  supports  TQPS20-style  command  completion  with  the  <escape> 
character,  and  allows  arbitrarily  long  file  names.  Moreover,  as  described  in 
detail  in  Appendix  A,  it  corrects  many  of  the  bugs  which  we  found  in  OBJT. 

The  only  disadvantage  is  that  it  will  not  run  on  DEC- 10  machines,  but  only  on 
20s.  Joseph  Tardo  is  a  student  at  UCLA  whose  just  completed  thesis[Tardo  81] 
is  on  these  implementations;  he  is  now  working  at  DEC. 

2.  Applications  and  Examples 

J.  Goguen  and  K.  Parsaye-Ghomi  have  written  a  paper  entitled  "Algebraic 
Denotational  Semantics  using  Parameterized  Abstract  Modules"  which  gives  some 
new  techniques  for  defining  the  semantics  of  programming  languages,  based  on 
the  features  of  OBJ.  These  techniques  are  illustrated  with  the  definition  of 
a  strongly  typed  programming  language  having  integer  and  boolean  expressions, 
conditionals,  iteration,  block  structure,  and  side-effect-only  procedures 
which  can  also  be  passed  as  parameters.  Because  procedures  can  be  passed  as 
values,  and  because  the  language  is  strongly  typed,  the  type  system  must  be 
higher  order. 

One  interesting  result  of  this  research  was  a  correspondence  between  some  of 
the  basic  constructions  in  denotational  semantics,  and  some  definitions  in  the 
OBJT  library  of  basic  parameterized  objects.  For  example,  the 
denotationalists'  Cartesian  product  of  domains  corresponds  to  PAIR  in 
<0BJT>LIB.0BJ,  and  the  denotationalists  function  domain  construction  (usually 
denoted  by  "arrow")  corresponds  to  ARRAY. 

The  paper  was  presented  at  the  "International  Conference  on  Formalization  of 
Programming  Concepts,"  held  in  Peniscola,  Spain,  this  April,  and  has  appeared 
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in  the  proceedings[Goguen  4  Parsaye-Ghomi  81].  An  improved  version  of  the 
language  definition  is  reproduced  in  Appendix  B  of  this  report.  This  version 
shows  better  how  the  OBJ  library  of  parameterized  specifications  is  used;  it 
better  illustrates  the  compilation  of  an  interpreter,  and  it  has  better 
mnemonics  and  better  test  cases.  Many  people  have  been  surprised  at  how  short 
and  modular  is  the  complete  definition  of  this  fairly  nontrivial  programming 
language,  and  how  easy  it  is  to  modify  it  to  get  definitions  of  related 
languages . 

Goguen  has  defined  a  new  data  type,  called  symboltree,  in  OBJ.  The  purpose  of 
this  data  type  is  to  provide  for  fast  checking  of  certain  information,  such  as 
the  types  of  variables,  during  interactive  editing.  The  definition,  and  a 
large  number  of  test  cases  showing  how  the  operations  of  the  data  type  work, 
is  given  in  Appendix  C  of  this  report. 

K.  Parsaye-Ghomi,  with  A.  B.  C.  Sampaio  of  UCLA,  has  written  a  specification 
of  a  hardware  multiplexor  in  OBJT;  a  rough  draft  paper  exists. 

In  response  to  a  challenge  from  Prof.  H.  Reichel  (of  Leipzig),  we  have  shown 
how  to  define  graphs,  and  paths  in  a  graph,  using  the  OBJ  error  algebra 
formalism,  rather  than  his  formalism  using  partially  defined  operations.  The 
OBJT  code  is  given  in  Appendix  F.  This  example  is  also  referred  to  in  Appendix 
F. 


We  have  discovered  some  rather  tricky  methods  to  achieve  certain  effects  which 
it  might  seem  cannot  be  done  in  OBJT,  such  as  higher  order  operations, 
defining  the  natural  numbers  from  the  integers,  and  imposing  new  equations  on 
old  objects.  These  are  illustrated  in  Appendix  E  to  this  report. 

3.  ihearatlcal  foundations 

Meseguer  and  Goguen  are  working  hard  on  the  basic  theory  of  error  algebras 
which  underlies  OBJ's  approach  to  error  definition,  handling,  and  recovery. 
Although  a  number  of  surprising  and  subtle  difficulties  have  been  uncovered, 
we  are  convinced  that  it  will  be  possible  to  get  correct  versions  of  all  the 
basic  algorithms  needed  for  OBJ-1 .  Current  efforts  are  centered  on  underlying 
semantic  issues,  and  on  the  relationship  to  partial  algebras. 

We  have  found  a  small  but  vicious  flaw  in  the  usual  deductive  system  for 
many-sorted  equational  logic,  as  used  for  example  in  most  work  on  abstract 
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data  types;  rather  shockingly,  this  system  is  not  sound.  Not  only  have  we 
given  some  new  axioms  which  are  sound  and  complete,  but  we  have  found 
sufficient  conditions  such  that  the  old  deduction  system  works  anywayCGoguen  & 
Meseguer  81].  Since  there  are  so  many  people  using  equations  now,  it  seems 
appropriate  that  this  paper  reach  the  fairly  broad  audience  which  reads 
SIGPLAM  Notices.  A  full  version  of  this  paper,  with  all  the  proofs,  is  in  an 
advanced  stage  of  preparation. 

Meseguer  has  written  a  deep  paper  entitled  "A  Birkhoff-like  Theorem  for 
Algebraic  Classes  on  Interpretations  of  Program  Schemes"  which  was  also 
presented  at  the  Peniscola  Conference,  and  appears  in  its  proceedings[Meseguer 
81].  This  work,  which  is  summarized  in  Appendix  G  to  this  report,  follows  up 
an  earlier  paper  "Varieties  of  Chain-complete  Algebras"  which  appeared  in  the 
prestigious  special  issue  of  the  Journal  of  Pure  and  Applied  Algebra  honoring 
the  sixtieth  birthday  of  Professor  Saunders  MacLane  of  the  University  of 
Chicago[Meseguer  80]. 

K.  Parsaye-Ghomi  has  developed,  as  part  of  his  nearly  completed  Ph.D. 
dissertation  at  UCLA,  a  method  for  extending  OBJ  to  handle  higher  order 
operations  and  equations.  We  have  found  that  this  would  be  extremely  useful 
in  the  specification  of  programming  languages,  as  illustrated  in[Goguen  & 
Parsaye-Ghomi  81].  The  thesis  and  some  papers  based  on  it  should  be  available 
soon. 

4.  Mack  aa  Belated  Specification  Languages 

R.  Burstall  and  J.  Goguen  have  written  an  informal  introduction  to  their 
powerful  specification  language  CLEAR[Burstall  4  Goguen  81].  This  paper, 
which  will  appear  in  the  Academic  Press  book  of  Liege  lectures,  with  papers  of 
Dijkstra,  Boyer  and  Moore,  and  Manna,  includes  a  sophisticated  specification 
of  a  garbage  collector. 

Burstall  and  Goguen  are  also  working  on  the  design  of  a  much  more 
user-oriented  specification  language  with  the  same  underlying  semantics  as 
CLEAR;  this  new  language  is  to  be  called  ORDINARY,  as  in  some  ways  it  also 
builds  on  the  previous  generation  SRI  specification  language  SPECIAL[Levitt, 
Robinson  &  Silverberg  79].  A  draft  report  is  available  on  this  subject[Goguen 
&  Burstall  80a] . 

Burstall  and  Goguen  are  also  working  on  a  program  design  system  which  will  be 
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based  on  their  previous  work  on  specification.  This  system  is  called  CAT,  and 
a  concept  piece  outlining  their  intentions  for  it  is  available  as  an  SRI 
technical  reporttGoguen  &  Burstall  80b]  and  is  included  with  this  report.  One 
general  idea  is  to  construct  a  program  transformation  system  which  explicitly 
addresses  the  very  important  fact  that  in  order  to  verify  correctness  of  an 
application  of  a  transformation,  it  is  necessary  to  know  some  parts  of  the 
theory  of  the  program,  and  to  understand  how  various  parts  of  the  theory  fit 
together  with  various  parts  of  the  program. 

[Burstall  A  Goguen  78]  gives  a  complete  formal  semantics  for  CLEAR,  the  first 
time  that  denotational  semantics  has  been  given  for  a  specification  language. 
[Goguen  &  Burstall  78]  gives  the  mathematical  background  on  theories  on  which 
[Burstall  &  Goguen  78]  is  based;  we  have  just  completed  final  revisions  of 
this  paper  for  publication. 

[Goguen  80]  gives  foundations  of  OBJ,  in  particular  for  the  use  of  rewrite 
rules  to  Implement  initial  algebras,  and  or  using  the  Knuth-Bendix  algorithm 
for  automatic  verification  for  algebraic  specifications. 

5.  Eubllsatlflna 
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III.  RESULTS  IN  PROGRESS 

This  section  sketches  some  results  which  are  now  in  progress. 

i .  Implementations 

One  of  the  basic  ideas  behind  OBJ  is  to  regard  equations  as  rewrite  rules,  so 
that  techniques  such  as  the  Knuth-Bendix  algorithm  can  be  used  for  execution 
and  verification.  D.  Smallberg  of  UCLA  is  working  on  a  version  of  the 
reduction  and  Knuth-Bendix  algorithms  which  can  handle  so-called  permuting 
axioms.  This  system,  called  KB,  is  being  written  in  C,  to  run  on  VAX 
machines.  It  will  not  have  all  the  features  of  OBJT,  such  as  mix-fix  syntax 
and  error  handling,  but  it  will  serve  as  testbed  for  the  eventual  integration 
of  these  ideas  in  an  OBJ-1  system.  The  design  and  implementation  of  KB  is 


Smallberg's  Ph.D.  thesis  topic. 


Also,  J.  Weiner  of  the  University  of  New  Hampshire  has  begun  work  on  an 
implementation  of  OBJ  in  Prolog.  This  should  be  more  efficient  than  the 
current  Rutgers-UCI  LISP  implementation,  although  it  will  not  include  all  its 
features.  It  will  also  be  highly  portable. 

2.  Foundations 

We  are  making  significant  progress  on  the  difficult  problems  arising  in  the 
theory  of  error  algebras,  by  making  use  of  advanced  mathematical  ideas  in 
works  such  astCoste  77]  and[Gabriel  Ulmer  71].  Some  of  our  ideas  are 
described  in  Appendices  F  and  G.  If  successful,  it  appears  that  this  approach 
will  subsume  all  the  various  algebraic  models  which  have  been  so  far  given  in 
the  literature.  A  major  difficulty  which  we  foresee  is  attempting  to  convey 
the  ideas  in  a  way  which  will  be  understandable  to  the  computer  science 
community  at  large. 


APPENDICES 

It  is  intended  that  the  material  in  these  appendices  should  provide  a  good 
practical  background  for  OBJT  users,  as  supplements  to[Goguen  &  Tardo  79] 
and[Tardo  81]. 


A  OBJT  SUGGESTIONS ,  BUGS  AND  COMMENTS 

This  is  a  compendium  of  various  discoveries  about  OBJ  and  its  implementations. 
Many  comments  (e.g.,  in  l.a  below)  relate  to  the  implementations  at  SRI-KL, 
namely  OBJT  and  0BJT20,  and  are  so  indicated,  while  others  will  apply  to  any 
implementation  based  on  the  same  design.  Also,  note  that  many  of  the  OBJT 
bugs  have  been  corrected  in  0BJT20.  Eventually  0BJT20  will  supersede  OBJT  and 
also  acquire  its  name. 

1.  Inout/Output 

a.  There  is  no  way  to  see  the  result  of  performing  an  IMAGE.  Perhaps  there 
could  be  a  flag  which  if  set  would  cause  the  result  of  performing  an  IMAGE  to 
be  displayed  whenever  IMAGE  is  executed.  This  flag  could  also  control  whether 
or  not  an  OUT  file  would  include  these  result  displays. 

This  raises  the  question  of  whether  it  is  desirable  to  display  built-in 
objects  such  as  INT.  One  possibility  is  to  display  just  the  syntax,  with  a 
comment  (•*•)  that  this  is  a  built-in  object;  a  second  possibility  is  to 
display  a  set  of  equations  which  define  the  object,  even  though  the  object  is 
not  actually  implemented  by  the  corresponding  rewrite  rules. 

b.  The  parsers  provide  no  help  when  an  expression  cannot  be  parsed.  It  is  a 
difficult  but  Interesting  problem  to  design  a  parser  which  will  provide  useful 
feedback  to  the  user  in  such  cases.  Probably  it  should  be  interactive. 

2.  IMAGE 

a.  Why  should  it  be  permitted  to  apply  IMAGE  to  built-in  objects  such  as  INT? 
(One  explanation  is  that  one  could  then  define  NAT  from  INT;  but  there  is  a 
better  way  to  do  that,  e.g.,  using  a  unary  prefix  operator,  such  as  #_  :  INT 
->  NAT,  and  a  suitable  error  equation.) 

b.  We  could  define  a  new  OBJ  "parameterized  object"  to  have  the  form  SORTS 
(<param-sort-list>)  <new-sort-list>  /  <old-sort-list>  [with  the  latter 
optional]  for  its  SORTS  declaration,  and  otherwise  the  same  syntax  as  present 
OBJT  objects.  Furthermore,  we  should  allow  only  such  parameterized  objects  to 
be  imaged,  with  only  their  parameter  sorts  being  mapped.  Furthermore,  if  not 
all  parameter  sorts  are  actually  mapped,  then  the  resulting  IMAGE  object  is 
also  parameterized,  and  this  should  be  indicated  in  the  same  way,  with 
parentheses . 


c.  It  should  not  be  permitted  to  have  duplicate  copies  of  ANY  objects  around, 
unless  they  have  different  names  for  the  object  and  for  new  sorts.  In 
particular,  IMAGE  should  not  create  duplicate  objects,  either  of  BOOL  or  of 
ar.y  other  objects. 

3.  RUM  &  PERMUTING 

a.  The  present  Implementations  have  a  bug  somewhere;  for  example,  ARRAY  with 
ADD  as  a  PERMUTING  operator  produces  strange  LISP-level  error  messages  when 
SYMBOLTABLE  (defined  by  IMAGE  as  an  ARRAY  of  STACKs)  is  run.  Similar  strange 
things  happen  if  it  is  RUMed  without  the  PERMUTING  declaration. 

b.  EQ  is  not  implemented  for  permuting  objects;  it  should  not  be  very 
difficult  to  extend  it  to  do  so. 

c.  It  would  be  useful  to  be  able  to  set  the  environment  of  a  RUN  to  any 

desired  object.  The  syntax 

RUN  /  <obJ-list>  <exp>  NUR 

is  one  possibility,  with  default  (if  there  is  no  "/  <obj-list>")  to  the 
previous  object,  as  at  present. 

4.  Files 

a.  It  would  be  nice  to  be  able  to  save  OBJT  working  states.  (Using  the 
operating  system  SAVE  seems  to  use  a  lot  of  memory.)  More  generally,  it  would 
be  nice  to  have  an  incremental  object  management  facility. 

5.  Updating  Objects 

a.  There  are  many  cases  where  one  wants  to  enrich  an  existing  object  with  some 
new  operations,  or  even  some  new  sorts,  and  it  is  a  drag  to  have  to  give  a  new 
name.  Even  worse,  one  might  like  to  take  an  existing  large  definition  and 
evolve  it  to  serve  some  new  purpose  by  changing  old  objects.  It  would  be  very 
nice  if  there  were  some  systematic  way  of  doing  this.  Here  is  a  suggestion: 
OBJ  <id>  /  <id>  ....  JBO,  where  <id>  is  an  identifier,  would  create  a  new 
object  <id>  which  enriches  the  old  one,  now  designated  <id> .  —  1 ;  and  all  old 
references  to  the  old  object  <id>  now  updated  to  become  references  to  <id>.-1. 
This  process  could  be  repeated  to  yield  objects  <id>.-2,  <id>.~3  etc. 

6.  AaflcslaUvlty 


OBJT  and  0BJT20  implement  something  which  is  fairly  close  to  associativity, 
but  more  efficient  to  run;  thus,  it  is  dangerous  to  rely  on  associativity 
working  correctly  in  complex  cases.  An  associative-operator,  pattern-matching 
algorithm  could  be  the  basis  of  a  new  implementation.  It  should  be  possible 
to  do  this  in  such  a  way  '■hat  the  simple  cases  are  still  executed  efficiently. 

7.  Knuth-Bendlx  Test 

It  is  far  from  clear  how  to  implement  a  Knuth-Bendix  algorithm  which  handles 
all  OBJ  features,  including  errors,  conditional  equations,  associativity  and 
permutativity.  The  current  implementation  however,  does  not  always  run 
correctly  even  on  classical  cases  which  involve  none  of  these  features. 

8 .  Syntax 

a.  It  would  be  convenient  for  some  applications  to  be  able  to  define 
operations  with  result  a  tuple  of  values  of  specified  sorts  (this  is  called 
"co-arity"  in  the  algebraic  literature) .  One  also  needs  to  be  able  to 
"untuple"  such  values.  For  this,  one  might  build  in  operations,  denoted  say 
1*,  2*,  3*.  ...  to  extract  (respectively)  the  first,  second,  third,  ... 
component . 

b.  Equations  of  the  form 

AS  S:  (X  =  BAD  IF  P(X)) 

which  would  be  very  useful  for  defining  subtypes,  such  as  NAT  as  a  subtype  of 
INT,  are  not  accepted.  (This  could  be  done  by  setting  S  =  NAT,  giving  a 
coercion  INT  ->  NAT,  and  letting  P(X)  be  X  <  0.) 

c.  (HIDDEN)  does  not  work  correctly  in  OBJT;  the  first  time  that  an  operation 
declared  HIDDEN  is  used  inside  the  object  where  it  is  declared,  one  gets  an 
"abnormal  termination"  warning  and  is  thrown  out  of  the  object.  (This  has 
been  corrected  in  0BJT20.) 

d.  It  would  be  nice  to  have  a  way  to  encapsulate  a  number  of  previously 
defined  objects,  declaring  all  but  some  subset  of  their  operations  to  be 
HIDDEN.  (See  ORDINARY  for  one  approach.) 

9.  Qfriflflta 

a.  The  type  NAT  of  natural  numbers  is  not  built-in.  It  should  be,  with  the 
obvious  coercion  from  NAT  to  INT. 
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b.  It  would  be  nice  if  the  quotes  (e.g.,  *A,  'B,  etc.)  were  not  necessary  for 
type  ID  of  identifiers. 

c.  OBJT  evaluates  some  BOOLean  expressions  wrong.  For  example, 

RUN  T  AND  (T  AND  T)  NUR 

yields  the  result  "T  AND  T".  Similarly  for  many  other  truth  values  and 
connectives.  (This  has  been  corrected  in  OBJT20.) 

10.  Trivial  Dut  Annoying 

a.  Input/Output 

Spacing  conventions  are  irregular  and  sometimes  confusing.  (These  have  all 
been  corrected  in  OB JT20 . ) 

(1) .  Comments  received  from  a  file  are  treated  reasonably,  but  comments 

acquired  directly  from  the  user  are  not  in  OBJT  (e.g.,  typing 
>••*  THIS  IS  A 

TWO  LINE  TEST  OF  COMMENTS.  ••• 

at  a  terminal  produces  a  rather  odd  distribution  of  characters) . 

(2) .  For  input  read  from  a  file,  warnings  after  a  RUN  skip  a  line,  and  the 

next  RUN  is  right  after  the  warning,  (e.g., 

>RUN  . 

warning :  . 

>RUN 

which  gives  the  impression  that  warning  goes  with  the  2nd  RUN). 

(3) .  The  built-in  OBJT  editor  in  not  so  easy  to  use;  it  would  probably  be 
better  to  use  something  like  EMACS. 

b.  Syntax 

(1) .  OBJ  should  not  object  to  using  numbers  as  operator  symbols.  Of  course, 
ambiguities  might  arise,  but  overloading  constants  is  no  worse  than 
overloading  operators  like  +  and  *.  (This  is  corrected  in  0BJT20.) 

(2) .  It  is  actually  difficult  to  use  keywords  spelled  backwards  as 

terminators,  because  one  makes  spelling  errors;  syntax  like 
OBJ  ...  ENDOBJ 
RUN  ...  ENDRUN 
IM  ...  ENDIM 

would  be  easier  to  remember  and  to  use  correctly. 
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(3).  The  name  "TEST"  for  the  flag  which  cauaea  OBJ  to  interpret  all  RUNs  aa 
RUMa  is  not  very  suggestive;  for  example,  "RUM"  would  be  better. 


B  PROGRAMMING  LANGUAGE  DEFINITION 

This  is  an  improved  version  of  the  programming  language  definition  in  [Goguen 
A  Parsaye-Ghoml  81]. 


[PHOTO:  Recording  initiated  Mon  6-Jul-8l  5:52PM] 

Link  from  GOGUEN,  TTY  10 

T0PS-20  Command  processor  3AC 37 )— 3 
End  of  <G0GUEN>C0MAND . CMD . 2 
80BJT20 


•••OBJT  4/17/81 


> 

LISP 


242  msec  CPU  (0  msec  GC) ,  2831  msec  clock,  64  conses 

• 

(REALLOC  10000  10000  10000  10000  310000) 

0BJT20  Running  at  411067  Load  1.57  Used  0:03:40.2  in  1:22:19 


(SBEGIN) 


> 

IN  LIB  MOD  NI 


HERE  IS  A  BASIC  LIBRARY  OF  PARAMETERIZED  TYPES  ••• 
OBJ  PAIR 

SORTS  PAIR  LEFT  RIGHT 
OK-OPS 

:  LEFT  RIGHT  ->  PAIR 
LEFT_  :  PAIR  ->  LEFT 
RIGHT_  :  PAIR  ->  RIGHT 

VARS 

LEFT  :  LEFT 
RIGHT  :  RIGHT 
P  :  PAIR 
OK-EQNS 

(LEFT  <  LEFT  ;  RIGHT  >  *  LEFT) 

(RIGHT  <  LEFT  ;  RIGHT  >  =  RIGHT) 

(<  LEFT  P  ;  RIGHT  P  >  =  P) 

JBO 
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1 


OBJ  ARRAY  /  BOOL 

SORTS  ARRAY  INDEX  ELEMENT 

OK-OPS 

■  NIL-ARRAY  :  ->  ARRAY 

PUT  :  INDEX  ELEMENT  ARRAY  ->  ARRAY 
_I_]  :  ARRAY  INDEX  ->  ELEMENT 
_IN_  :  INDEX  ARRAY  ->  BOOL 
ERR-OPS 

UNDEF  :  INDEX  ->  ELEMENT 

VARS 

A  :  ARRAY 
II':  INDEX 
ELM  :  ELEMENT 
OK-EQNS 

(PUT(I,ELM,A)[  I  ]  =  ELM) 

(PUT (I, ELM, A) [  I»  ]  =  A  [  I'  ]  IF  NOT  I  ==  I') 
I  (I  IN  NIL-ARRAY  =  F) 

(I  IN  PUT (I ' ,ELM, A)=  I  ==  I'  OR  I  IN  A) 
ERR-EQNS 

!  (A  [  I  ]  =  UNDEF(I)IF  NOT  I  IN  A) 

JBO 


OBJ  LIST  /  BOOL 
SORTS  LIST  ELEMENT 
OK-OPS 

NIL  :  ->  LIST 
_  :  ELEMENT  ->  LIST 

:  LIST  LIST  ->  LIST  (ASSOCIATIVE) 
EMPTY?  :  LIST  ->  BOOL 
FIRST  :  LIST  ->  ELEMENT 
REST  :  LIST  ->  LIST 
ERR-OPS 

NO-FIRST  :  ->  LIST 
NO-REST  :  ->  LIST 

VARS 

L  :  LIST 


JBO 


OBJ  STACK  /  BOOL 
SORTS  STACK  ELEMENT 
OK-OPS 

EMPTY  :  ->  STACK 
POP_  :  STACK  ->  STACK 
PUSH  :  ELEMENT  STACK  ->  STACK 
TOP_  :  STACK  ->  ELEMENT 
EMPTY?_  :  STACK  ->  BOOL 
ERR-OPS 

UNDERFLOW  :  ->  STACK 
NO-TOP  :  ->  ELEMENT 

VARS 

ELM  :  ELEMENT 
S  :  STACK 
OK-EQNS 

(POP  PUSH(ELM,S)=  S) 

(TOP  PUSH(ELM,S)=  ELM) 

(EMPTY?  PUSH(ELM,S)=  F) 
(EMPTY?  EMPTY  =  T) 

ERR-EQNS 

(POP  EMPTY  =  UNDERFLOW) 

(TOP  EMPTY  =  NO-TOP) 

JBO 


=End  of  files 


WE  BEGIN  BY  DEFINING  THE  BASIC  COMPONENTS  OF  STATES 

ill 

•••  THE  STORABLE  VALUES  OF  MODEST  ARE  TYPE-VALUE  PAIRS 
WHICH  ARE  CALLED  ITEMS  ••• 

IM  (PAIR  =>  ITEM1 ) 

SORTS  (PAIR  =>  ITEM) 

(LEFT  =>  TYPE) 

(RIGHT  =>  VALUE) 

OPS  (<_;_>  :  LEFT  RIGHT  ->  PAIR  =>  <_:_>) 

(LEFT_  :  PAIR  ->  LEFT  =>  TYPE-OF_) 

(RIGHT_  :  PAIR  ->  RIGHT  =>  VALUE-OF_) 

MI 


OBJ  ITEM  /  ITEM1 
OK-OPS 

UNDEFINED-TYPE  :  ->  TYPE 
UNDEFINED-VALUE  :  ->  VALUE 
UNDEFINED-ITEM  :  ->  ITEM 
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JBO 


•••  A  TAPE  IS  A  LIST  OF  ITQ1S  *•» 

IM  (LIST  =>  TAPE)/  ITEM  BOOL 
SORTS  (LIST  =>  TAPE) 

(ELEMENT  =>  ITEM) 

OPS  (NO-REST  :  ->  LIST  =>  END-OF-TAPE) 
MI 


IM  (PAIR  =>  I /O-TAPES)/  TAPE 
SORTS  (PAIR  =>  I /O-TAPES) 

(LEFT  =>  TAPE) 

(RIGHT  =>  TAPE) 

OPS  (LEFT_  :  PAIR  ->  LEFT  =>  INPUT-0F_) 

(RIGHT_  :  PAIR  ->  RIGHT  =>  OUTP(JT-OF_) 
MI 


•••  FROM  THE  INTEGERS, HE  CONSTRUCT  FIRST  AN  ENRICHMENT 
WITH  MORE  OPERATIONS, AND  THEN  AN 
ABSTRACTION, WITH  FEWER  ••• 

OBJ  INTE  /  INT  BOOL 
OK-OPS 

_<=__  :  INT  INT  ->  BOOL 
_=>_  :  INT  INT  ->  BOOL 
VARS 

I  J  :  INT 
OK-EQNS 

(I  <=  J  =  NOT (I  >  J)) 

(I  =>  J  =  NOT (I  <  J)) 

JBO 


OBJ  LOC  /  INT 
SORTS  LOC 
OK-OPS 

_  :  INT  ->  LOC 
NEXT_  :  LOC  ->  LOC 

VARS 

I  :  INT 
OK-EQNS 

(NEXT  1=1+1) 

JBO 


IM  (ARRAY  =>  STORE)/  LOC  ITEM  BOOL 
SORTS  (ARRAY  =>  STORE) 
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(ELEMENT  =>  ITEM) 

(INDEX  =>  LOC) 

OPS  (NIL-ARRAY  :  ->  ARRAY  =>  NIL-STORE) 
MI 


IM  (PAIR  =>  STATE)/  STORE  I/O-TAPES  BOOL 
SORTS  (PAIR  =>  STATE) 

(LEFT  =>  STORE) 

(RIGHT  =>  I/O-TAPES) 

OPS  (LEFT_  :  PAIR  ->  LEFT  =>  MEMERY-OF_) 
(RIGHT_  :  PAIR  ->  RIGHT  =>  TAPE-OF_) 
MI 


OBJ  MAKE-STATE  /  STATE 
OK-OPS 

PUT  :  LOC  ITEM  STATE  ->  STATE 
_[_]  :  STATE  LOC  ->  ITEM 
_JN_  :  LX  STATE  ->  BXL 
NIL-STATE  :  ->  STATE 

VARS 

ITEM  :  ITQ1 
STORE  :  STORE 
L  :  LX 

TAPE  :  I/O-TAPES 
OK-EQNS 

(PUT (L, ITEM, <  STORE  ;  TAPE  >)=  <  PUT(L,ITEM, 
STORE);  TAPE  >) 

(<  STORE  ;  TAPE  >  [  L  ]  =  STORE  [  L  ]) 

(L  IN  <  STORE  ;  TAPE  >  =  L  IN  STORE) 
(NIL-STATE  =  <  NIL-STORE  ;  <  NIL  ;  NIL  >  >) 

JBO 


OBJ  I/O  /  MAKE-STATE 
OK-OPS 

READ-NEXT-INPUT  :  STATE  ->  ITEM 
WRITE-NEXT-OUTPUT  :  ITEM  STATE  ->  STATE 
INITIAL-STATE  :  TAPE  ->  STATE 
SET-INPUT  :  STATE  ->  STATE 

VARS 

STORE  :  STORE 
IN-TAPE  OUT-TAPE  :  TAPE 
STATE  :  STATE 
ITEM  :  ITEM 
OK-EQNS 

(READ-NEXT-INPUT (<  STORE  ;  <  IN-TAPE  ;  OUT -TAPE 
>  >)=  FIRST(IN-TAPE) ) 

(WRITE-NEXT -OUTPUT (ITEM , <  STORE  ;  <  IN-TAPE  ; 
OUT-TAPE  >  >)=  <  STORE  ;  <  IN-TAPE  ;( 


OUT -TAPE  ;  ITEM)>  >) 

UNIT IAL-ST ATE ( I N -T APE ) =  <  NIL-STORE  ;  <  IN-TAPE 
;  NIL  >  >) 

(SET-INPUT(<  STORE  ;  <  IN-TAPE  ;  OUT-TAPE  >  >)  = 

<  STORE  ;  <  REST (IN-TAPE);  OUT-TAPE  >  >) 

JBO 


OBJ  ALLOCATION  /  I/O 
OK-OPS 

ALLOCATE  :  STATE  ->  LOC 
INITIALIZE  :  TYPE  STATE  ->  STATE 
INITIALIZE  :  ITEM  STATE  ->  STATE 
FIND-NEXT  :  LOC  STATE  ->  LOC 
VARS 

TYPE  :  TYPE 
STATE  :  STATE 
ITEM  :  ITEM 
LOC  :  LOC 
OK-EQNS 

( ALLOCATE ( STATE ) =  FIND-NEXT(1 .STATE)) 

(FIND-NEXT (LOC, STATE )=  IP  NOT(LOC  IN  STATE) THEN 
LX  ELSE  FIND-NEXT  ((NEXT  LX) ,  STATE)  FI) 

( INITIALIZE(TYPE , STATE ) =  PUT ( ALLX ATE (STATE ) , < 
TYPE  :  UNDEFINED- VALUE  >, STATE)) 
(INITIALIZE( ITEM , ST ATE ) =  PUT ( ALLOCATE (STATE ) , 
ITEM, STATE)) 

JBO 


IM  (ARRAY  =>  LAYER)/  ID  LX  BOOL 
SORTS  (ARRAY  =>  LAYER) 

(INDEX  =>  ID) 

(ELEMENT  =>  LOC) 

OPS  (NIL-ARRAY  :  ->  ARRAY  =>  NIL-LAYER) 
MI 


IM  (STACK  =>  SYMBOL-TABLE)/  LAYER  BXL 
SORTS  (STACK  =>  ENV) 

(ELEMENT  =>  LAYER) 

OPS  (EMPTY  :  ->  STACK  =>  NIL-ENV) 

(POP_  :  STACK  ->  STACK  =>  EXITBLXK-) 
MI 


IM  (LIST  s>  ID-LIST)/  ID  BXL 
SORTS  (LIST  =>  ID-LIST) 
(ELEMENT  =>  ID) 

MI 
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OBJ  ENVIRONMENT  /  SYMBOL-TABLE  ID-LIST  ALLOCATION 
OfC-OPS 

ENTERBLOCK^  :  ENV  ->  ENV 
GET  :  ENV  ID  ->  LOC 
RETRIEVE  :  ID  ENV  STATE  ->  ITEM 
BIND  :  ID-LIST  ENV  STATE  ->  ENV 
ERR-OPS 

UNDECL  :  ID  ->  LOC 

_ALREADY -DECLARED-IN-BLOCK  :  ID  ->  ENV 
VARS 

ENV  :  ENV 
ID  :  ID 
LAY  :  LAYER 
STATE  :  STATE 
ID-L  :  ID-LIST 
OK-EQNS 

(ENTERBLOCK  ENV  =  PUSH (NIL-LAYER , ENV) ) 

(GET ( EN  V ,  ID )  = (TOP  ENV)[  ID  ]  IF  ID  IN  TOP  ENV) 
(GET (ENV, ID)=  GET(EXITBLOCK  ENV, ID)IF(NOT(ID  IN 
TOP  ENV))) 

( RETRIEVE (ID, ENV, STATE )=  STATE  [  GET (ENV, ID) ] ) 
(BIND (ID, PUSH (LAY, ENV) , STATE )=  PUSH (PUT (ID, 

ALLOC ATE (STATE) ,LAY) ,ENV) ) 

(BIND (ID  ;  ID-L, ENV, STATE )=  BIND (ID-L, BIND (ID, 
ENV, STATE), (INITIALIZE(UNDEFINED-ITEM, STATE 
)))) 

ERR-EQNS 

(GET(NIL-ENV, ID)=  UNDECL (ID) ) 

( BIND ( ID , PUSH ( LA Y , EN V ) , STATE ) =  ID 

ALREADY -DECLARED-IN-BLOCK  IF (ID  IN  LAY)) 

JBO 


HE  NOW  DEFINE  INTEGER  AND  BOOLEAN  EXPRESSIONS  ••• 

OBJ  EXPRESSION  /  ENVIRONMENT 

SORTS  EXP 

OK-OPS 

_  :  ID  ->  EXP 

VALUE  :  EXP  ENV  STATE  ->  ITEM 
TYPE  :  EXP  ENV  STATE  ->  TYPE 

VARS 

EXP  :  EXP 
ENV  :  ENV 
STATE  :  STATE 
ID  :  ID 
I  J  :  ITEM 
OK-EQNS 

(VALUE ( ID , ENV , STATE ) =  RETRIEVE ( ID , EN V , STATE ) ) 
(TYPE(EXP, ENV, STATE) =  TYPE-OF  VALUE (EXP, ENV, 
STATE)) 


JBO 


OBJ  INT-EXP  /  EXPRESSION 
OK-OPS 

INT  :  ->  TYPE 
_  :  INT  ->  VALUE 
INT-VAL  :  ITEM  ->  INT 
_  :  INT  ->  EXP 

:  EXP  EXP  ->  EXP 

:  EXP  EXP  ->  EXP 

:  EXP  EXP  ->  EXP 

ERR-OPS 

_J)OES-NOT-MATCH_  :  TYPE  TYPE  ->  VALUE 
VARS 

I  :  INT 
ENV  :  ENV 
STATE  :  STATE 
EXP  EXP'  :  EXP 
TYPE  :  TYPE 
VALUE  :  VALUE 
OK-EQNS 

( INT-VAL (<  INT  :  I  >)=  I) 

( V ALUE(I, ENV, STATE )=  <  INT  :  I  >) 

(VALUE (EXP  +  EXP ' ,ENV,STATE)=  <  INT  :(INT-VAL( 
VALUE(EXP, ENV, STATE) )+  INT-VAL(VALUE(EXP ' , 
ENV, STATE) ))>) 

( VALUE(EXP  -  EXP' , ENV, STATE )=  <  INT  :(INT-VAL( 
VALUE (EXP, ENV, STATE))-  INT-VAL( VALUE (EXP ' , 
ENV .STATE) ) ) > ) 

(VALUE(EXP  •  EXP' , ENV, STATE )=  <  INT  :(INT-VAL( 
VALUE (EXP, ENV, STATE))*  INT-VAL (VALUE (EXP ’ , 
ENV, STATE) ) )> ) 

ERR-EQNS 

( INT-VAL (<  TYPE  :  VALUE  >)=  TYPE  DOES-NOT -MATCH 
INT  IF(NOT(TYPE  ==  INT))) 

JBO 


0BJT20  Running  at  405005  Load  3-87  Used  0:04:44.9  in  1:25:16 

OBJ  BOOL-EXP  /  INTE  INT-EXP 
OK-OPS 

BOOL  :  ->  TYPE 
_  :  BOOL  ->  VALUE 
BOOL-VAL  :  ITEM  ->  BOOL 
_  :  BOOL  ->  EXP 


__AND_ 

:  EXP  EXP  ->  EXP 

_0R_ 

EXP  EXP  ->  EXP 

NOT_ 

EXP  ->  EXP 

_EQ_ 

EXP  EXP  ->  EXP 

_<=_ 

EXP  EXP  ->  EXP 

: 

EXP  EXP  ->  EXP 
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ERR-OPS 

TYPE-CONFLICT  :  ->  ITEM 

VARS 

B  :  BOOL 
TYPE  :  TYPE 
ENV  :  ENV 
STATE  :  STATE 
VALUE  :  VALUE 
EXP  EXP1  :  EXP 
I  J  :  INT 

OK-EQNS 

(BOOL-VAL(<  BOOL  :  B  >)=  B) 

(VALUE(B,ENV,STATE)=  <  BOOL  :  B  >) 

(VALUE (EXP  AND  EXP' , ENV, STATE )=  <  BOOL  :( 

BOOL-VAL ( VALUE (EXP , ENV , STATE ) )AND  BOOL-VAL( 
VALUE (EXP ' , ENV, STATE) ) )> ) 

(VALUE(EXP  OR  EXP ' , ENV, STATE)=  <  BOOL  :( BOOL-VAL 
(VALUE(EXP, ENV, STATE) )OR  BOOL-VAL (VALUE ( 

EXP ' , ENV , STATE ) ) ) > ) 

(VALUE (NOT  E XP, ENV, STATE )=  <  BOOL  : (NOT (BOOL-VAL 
(VALUE (EXP ,  EM  V, STATE) ) ) )> ) 

(VALUE (EXP  EQ  EXP ', ENV , STATE ) =  <  BOOL  :( VALUE ( 
EXP, ENV, STATE) ==  VALUE (EXP ', ENV, STATE) )>) 
(VALUE(EXP  <=  EXP' , ENV, STATE )=  <  BOOL  :(INT-VAL( 
VALUE(EXP, ENV, STATE) )<=  INT-VAL(VALUE(EXP • , 
ENV, STATE)) )>) 

(VALUE(EXP  >  EXP' , ENV, STATE )=  <  BOOL  :(INT-VAL( 
VALUE(EXP  ENV, STATE) )>  INT-VAL(VALUE(EXP ' , 
ENV, STATE) ) ) > ) 

ERR-EQNS 

(BOOL-VAL(<  TYPE  :  VALUE  >)=  TYPE  DOES-NOT-MATCH 
BOOL  IF  NOT(TYPE  ==  BOOL)) 

(VALUE(EXP  EQ  EXP ', ENV, STATE )=  TYPE-CONFLICT  IF 
NOT(TYPE(EXP , ENV,STATE)==  TYPE (EXP ', ENV, 
STATE))) 

( VALUE(EXP  <=  EXP' ,ENV,STATE)=  TYPE-CONFLICT  IF 
NOT(TYPE(EXP , ENV, STATE )==  INT  AND  TYPE(EXP’ 
,ENV,STATE)==  INT)) 

(VALUE(EXP  >  EXP' , ENV, ST ATE) =  TYPE-CONFLICT  IF 
NOT(TYPE(EXP,ENV,STATE)==  INT  AND  TYPE(EXP' 
,ENV,STATE)==  INT)) 

JBO 


*»  WE  NOW  DEFINE  VARIOUS  STATEMENTS  AND  THEIR  MEANINGS 

HI 

IM  (LIST  =>  STMT-LIST)/  BOOL 
SORTS  (LIST  =>  STMT-LIST) 

(ELEMENT  =>  STMT) 

MI 
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OBJ  EXECUTION  /  STMT-LIST  ENVIRONMENT  I/O 

SORTS  PROGRAM 

OK-OPS 

EXECUTE.  :  PROGRAM  ->  TAPE 
EVAL  :  STMT-LIST  ENV  STATE  ->  STATE 
_WITH-INPUT_  :  STMT-LIST  TAPE  ->  PROGRAM 
VARS 

TAPE  :  TAPE 
STMT-L  :  STMT-LIST 
OK-EQNS 

(EXECUTE (STMT-L  WITH-INPUT  TAPE)=  OUTPUT-OF( 
TAPE-OF(EVAL(STMT-L,NIL-ENV,INITIAL-STATE( 
TAPE))))) 

JBO 


FIRST  SEMICOLON  «* 

OBJ  SEMICOLON  /  EXECUTION 
VARS 

STMT  :  STMT 
STMT-L  :  STMT-LIST 
ENV  :  ENV 
STATE  :  STATE 
OK-EQNS 

(EVAL (STMT  ;  STMT-L, ENV, STATE )=  EVAL (STMT-L, ENV, 
EVAL ( STMT , EN V , STATE ) ) ) 

JBO 


•••  DEFINE  BLOCK  STRUCTURE  «* 

IM  (LIST  =>  DECL-LIST)/  BOOL 
SORTS  (LIST  =>  DECL-LIST) 

(ELEMENT  =>  DECLARATION) 
OPS  (NIL  :  ->  LIST  =>  NILDECL) 
MI 


OBJ  DECLARATION  /  DECL-LIST  BOOL-EXP 
OK-OPS 

:  ID  TYPE  ->  DECLARATION 
DECLARE-ENV  :  DECL-LIST  ENV  STATE  ->  ENV 
DECLARE  :  DECL-LIST  STATE  ENV  ->  STATE 

VARS 

D  :  DECLARATION 
DL  :  DECL-LIST 
ENV  :  ENV 
ID  :  ID 
TYPE  :  TYPE 
ID-L  :  ID-LIST 
STATE  :  STATE 
OK-EQNS 
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(DECLARED  ;  DL, STATE, ENV)s  DECLARE ( DL , DECLARE ( D 
, STATE , ENV ) , DECLARE-ENV (D , EN V , STATE ) ) ) 

( DECLARE-ENV (D  ;  DL,ENV,STATE)=  DECLARE-ENV (DL , 
DECLARE-ENV ( D , EN V , STATE ) , INITIALIZE( 
UNDEFINED-ITEM .STATE) ) ) 

(DECLARE(ID  :  TYPE, STATE, ENV )=  INITIALIZE(T YPE , 
STATE)) 

(DECLARE-ENV (ID  :  TYPE, ENV, STATE):  BIND(ID,ENV, 
STATE)) 

JBO 


OBJ  BLOCK  /  DECLARATION  EXECUTION 

SORTS  BLOCK 

OK-OPS 

:  DECL-LIST  STMT-LIST  ->  BLOCK 
BEGIN _ END  :  BLOCK  ->  STMT 

VARS 

DCL-L  :  DECL-LIST 
STMT-L  :  STMT-LIST 
ENV  :  ENV 
STATE  :  STATE 
OK-EQNS 

(EVAL( BEGIN  DCL-L  ;  STMT-L  END, ENV, STATE):  EVAL( 
STMT-L , DECLARE-ENV (DCL-L , ENTERBLOCK  ENV , 
STATE) ,DECLARE(DCL-L, STATE, ENTERBLOCK  ENV)) 
) 

JBO 


DEFINE  ASSIGNMENT  «» 

OBJ  ASSIGNMENT  /  EXECUTION  BOOL-EXP 
OK-OPS 

:  ID  EXP  ->  STMT 

ASSIGN  :  ID  ITEM  ENV  STATE  ->  STATE 
ERR-OPS 

TYPE-OF_CONFLICTS_  :  ID  ITEM  ->  STATE 

VARS 

ID  :  ID 
EXP  :  EXP 
ENV  :  ENV 
STATE  :  STATE 
ITEM  :  ITEM 
OK-EQNS 

(EVAL(ID  :=  EXP, ENV, STATE):  ASSIGN (ID, VALUE (EXP, 
ENV , STATE ) , ENV , ST ATE ) ) 

( ASSIGN ( ID , ITEM , ENV .STATE ) :  PUT (GET (ENV , ID ) , ITEM 
.STATE)) 

ERR-EQNS 

(ASSIGN (ID, ITEM, ENV, STATE):  TYPE-OF  ID  CONFLICTS 
ITEM  IF  NOT(TYPE-OF  RETRIEVE(ID, ENV, STATE) 
::  TYPE-OF  ITEM)) 
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•••  DEFINE  READ  AND  PRINT  STATEMENTS 


OBJ  INPUT-OUTPUT  /  EXECUTION  ASSIGNMENT 
OK-OPS 

READ_  :  ID  ->  STMT 
PRINT_  :  EXP  ->  STMT 
ERR-OPS 

NO-INPUT -A VAILABLE-FOR_  :  ID  ->  STATE 

VARS 

ID  :  ID 
ENV  :  ENV 
STATE  :  STATE 
EXP  :  EXP  * 

STORE  :  STORE 
OUT-TAPE  :  TAPE 
OK-EQNS 

(EVAL(READ  ID, ENV, STATE):  ASSIGN(ID, 

READ-NEXT-INPUT (STATE ) , EN V , SET-INPUT (STATE ) 

)) 

(EVAL(PRINT  EXP, ENV, STATE):  WRITE-NEXT-OUTPUT ( 
VALUE (EXP , ENV , ST ATE ) , ST ATE ) ) 

ERR-EQNS 

(EVAL(READ  ID, ENV, <  STORE  ;  <  NIL  ;  OUT-TAPE  >  > 
)=  NO-INPUT -A VAILABLE-FOR  ID) 

JBO 


DEFINE  CONDITIONAL 

OBJ  CONDITIONAL  /  EXECUTION  BOOL-EXP  STMT-LIST 
OK-OPS 

IF:_THEN_ELSE_:FI  :  EXP  STMT-LIST  STMT-LIST  -> 
STMT 

VARS 

EXP  :  EXP 

STMT-L  STMT-L'  :  STMT-LIST 
ENV  :  ENV 
STATE  :  STATE 
OK-EQNS 

(EVAL(IF:  EXP  THEN  STMT-L  ELSE  STMT-L*  :FI,ENV, 
STATE):  EVAL (STMT-L , ENV, ST ATE) IF  BOOL-VAL( 
VALUE (EXP , ENV, STATE) ):=  T) 

(:  EVAL(STMT-L* ,ENV,STATE)IF  BOOL-VAL( VALUE (EXP, 
ENV, STATE))::  F) 

JBO 


DEFINE  ITERATION  •« 

OBJ  ITERATION  /  EXECUTION  BOOL-EXP  STMT-LIST 
OK-OPS 


WHILE JD 0_0D  :  EXP  STMT-LIST  ->  STMT 

VARS 

EXP  :  EXP 

STMT-L  :  S2WT-LIST 
ENV  :  ENV 
STATE  :  STATE 
OK-EQNS 

(EVAL(WHILE  EXP  DO  STMT-L  OD, ENV, STATE)*  EVAL< 
STMT-L  ;  WHILE  EXP  DO  STMT-L  OD, EHV, STATE) 
IF  BOOL-VAL(VALUE(EXP, ENV, STATE) )==  T) 

(=  STATE  IF(BOOL-VAL(VALUE(EXP,ENV,STATE))=*  F) ) 

JBO 


*•*  THIS  OBJECT  SUMMARIZES  ALL  STATEMENT  DEFINITIONS  ••• 

OBJ  STATQ1ENTS  /  EXECUTION  SEMICOLON  BLOCK 

ASSIGNMENT  CONDITIONAL  INPUT-OUTPUT 
ITERATION 

JBO 


1,1  WE  NOW  BEGIN  DEFINING  PROCEDURES  *«• 

IM  (PAIR  =>  PROC-DEFN)/  STMT-LIST  ID-LIST  BOOL 
SORTS  (PAIR  =>  PROC-DEFN) 

(LEFT  =>  ID-LIST) 

(RIGHT  =>  STMT-LIST) 

OPS  (LEFT_  :  PAIR  ->  LEFT  =>  FORMALS-OF_) 
(RIGHT_  ;  PAIR  ->  RIGHT  =>  STMT-OF_) 

MI 


IM  (PAIR  =>  CONTOUR)/  PROC-DEFN  ENVIRONMENT  BOOL 
SORTS  (PAIR  =>  CONTOUR) 

(LEFT  =>  PROC-DEFN) 

(RIGHT  =>  ENV) 

OPS  (LEFT_  :  PAIR  ->  LEFT  =>  DEFN-OF_) 

(RIGHT_  :  PAIR  ->  RIGHT  =>  ENV-OF_) 

MI 


IM  (LIST  =>  PARAM-DECL-LIST ) /  BOOL 
SORTS  (LIST  =>  PARAM-DECL-LIST) 
(ELEMENT  =>  PARAM-DECL) 

MI 


IM  (LIST  =>  TYPE-LIST)/  ITEM  BOOL 
SORTS  (LIST  =>  TYPE-LIST) 

(ELEMENT  =>  TYPE) 
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OPS  (NIL  :  ->  LIST  =>  VOID) 
MI 


IM  (LIST  =>  EXP -LIST)/  BOOL-EXP  BOOL 
SORTS  (LIST  =>  EXP -LIST) 

(ELEMENT  =>  EXP) 

MI 


OBJ  PROCEDURES  /  CONTOUR  TYPE-LIST  EXP-LIST 
PARAM-DECL-LIST  DECLARATION 
SORTS  PROC-DECL 
OK-OPS 

PROC[_]  :  TYPE-LIST  ->  TYPE 
_  :  CONTOUR  ->  VALUE 
_  :  PROC-DECL  ->  DECLARATION 
CONTOUR-VAL  :  ITEM  ->  CONTOUR 
PROC_I_]JEND  :  ID  PARAM-DECL-LIST  STMT-LIST  -> 
PROC-DECL 

:  ID  TYPE  ->  PARAM-DECL 
CALL  T  1  :  ID  EXP-LIST  ->  STMT 

VARS 

TYPE-L  :  TYPE-LIST 
C  :  CONTOUR 
TYPE  :  TYPE 
VALUE  :  VALUE 
OK-EQNS 

( CONTOUR -VAL(<  PROCt  TYPE-L  ]  :  C  >)=  C) 

ERR-EQNS 

( CONTOUR-VAL (<  TYPE  :  VALUE  >)=  TYPE 

DO ES-NOT -MATCH  PROC[  VOID  )  IF((TYPE  ==  INT 
)OR(TYPE  ==  BOOL))) 

JBO 


OBJ  PROC-DECLARATION  /  PROCEDURES 
OK-OPS 

GET-ID  :  PARAM-DECL-LIST  ->  ID-LIST 
GET-TYPE  :  PARAM-DECL-LIST  ->  TYPE-LIST 
VARS 

ID  :  ID 

PM-L  :  PARAM-DECL-LIST 
STMT-L  :  STMT-LIST 
ENV  :  ENV 
STATE  :  STATE 
PM  :  PARAM-DECL 
TYPE  :  TYPE 
OK-EQNS 

(DECLARE-ENV (PROC  ID  [  PM-L  ]  STMT-L  END, ENV, 
STATE )=  BIND (ID, ENV, ST ATE)) 
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( DECLARE (P ROC  ID  [  PM-L  ]  STMT-L  END, STATE, ENV)s 
IN1TIALIZE( ( < ( PROC [  GET-TYPE ( PM-L )]):(<(< 
GET -ID (PM-L);  STMT-L  >);  DECLARE-EN V ( P ROC 
ID  [  PM-L  ]  STMT-L  END, ENV, STATE )>)>) .STATE 
)) 

(GET-TYPE(PM  ;  PM-L)=  GET-TYPE(PM) ;  GET-TYPE( 
PM-L)) 

(GET-TYPE (ID  :  TYPE)*  TYPE) 

(GET -ID (PM  ;  PM-L)=  GET-ID(PM) ;  GET -ID (PM-L) ) 
(GET-ID(ID  :  TYPE)=  ID) 

JBO 


OBJ  PAR AM-P ASS-BY-VALUE  /  PROC-DECLARATION 
OK-OPS 

PASS-ENV  :  ID  ENV  STATE  ->  ENV 
PASS  :  EXP-LIST  STATE  ENV  ->  STATE 
GET-ENV  :  ID  ENV  STATE  ->  ENV 
GET-PARAMS  :  ID  ENV  STATE  ->  ID-LIST 
VARS 

EXP  :  EXP 
EXP-L  :  EXP-LIST 
ID  :  ID 

STMT-L  :  STMT-LIST 
STATE  :  STATE 
ENV  :  ENV 
OK-EQNS 

(PASS (EXP  ;  EXP-L .STATE, ENV )=  PASS(EXP-L,PASS( 
EXP, STATE, ENV), ENV)) 

(PASS (EXP, STATE, ENV)z  INITIALI2E(VALUE(EXP,ENV, 
STATE), STATE)) 

( P ASS-ENV( ID , ENV , STATE ) =  BIND (GET-PARAMS ( ID , ENV , 
STATE), GET -ENV(ID, ENV, STATE), STATE)) 

(GET -P  ARAMS ( ID , ENV , ST ATE ) =  FORM ALS-OF ( DEFN-OF 
CONTOUR-VAL (VALUE ( ID , ENV , STATE ) ) ) ) 

(GET -ENV (ID, ENV, STATE )=  ENTERBLOCK  ENV-OF 
CONTOUR-VAL (VALUE ( ID , ENV , STATE ) ) > 

JBO 


OBJ  CALL-BY-VALUE  /  PARAM-PASS-BY-VALUE  EXECUTION 
OK-OPS 

CALL-OK?  :  ID  EXP-LIST  ENV  STATE  ->  BOOL 
LIST-TYPE  :  EXP-LIST  ENV  STATE  ->  TYPE-LIST 
GET-STMT  :  ID  ENV  STATE  ->  STMT-LIST 
ERR-OPS 

PARAMS-OF_MISMATCH_  :  ID  EXP-LIST  ->  BOOL 

VARS 

ID  :  ID 

EXP-L  :  EXP-LIST 
EXP  :  EXP 
ENV  :  ENV 
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STATE  :  STATE 

OK-EQNS 

(EVAL(CALL  ID  [  EXP-L  ],ENV,STATE)=  EVAL( 
GET-STMT(ID , ENV , STATE ) , PASS-EH V ( ID , EN V , 
STATE) , PASS (EXP-L , STATE , ENV ) )IF  CALL-OK? (ID 
, EXP-L, ENV, ST ATE)) 

(CALL-OK?(ID, EXP-L, ENV, STATE)=  T  IF(TYPE(ID,ENV, 
STATE )==  PROC[  LIST-TYPE(EXP-L, ENV, STATE))) 
) 

(GET-STMT(ID, ENV, STATE) =  STMT-OF  DEFN-OF 
CONTOUR -VAL (VALUE (ID , ENV , STATE) ) ) 

( LIST-TYPE (EXP , ENV , STATE ) =  T YPE ( EXP , EN V , STATE ) ) 

(LIST-TYPE (EXP  ;  E XP -L, ENV, STATE )=  TYPE(EXP,ENV, 
STATE);  LIST-TYPE (EXP-L, ENV, STATE) ) 

ERR-EQNS 

(CALL-OK? (ID, EXP -L,ENV,STATE)=  PARAMS-OF  ID 

MISMATCH  EXP-L  IF(NOT(TYPE(ID,ENV,STATE)== 
PROC£  LIST-TYPE (EXP-L , ENV , STATE ) ] ) ) ) 

JBO 


•»»  HE  NOW  SUM  UP  ALL  THE  FEATURES  OF  MODEST  ••• 

OBJ  MODEST  /  STATEMENTS  CALL-BY-VALUE 
JBO 


=End  of  file= 

EXIT 

% 

$;WE  NOW  SAVE  THE  RESULTS  OF  0BJT20’S  PROCESSING  OF  THIS 
DEFINITION  IN  A  FILE  TO  WHICH  WE  CAN  RETURN  LATER  FOR 
§; EXECUTION.  IN  EFFECT,  WE  HAVE  COMPILED  AN  INTERPRETER 
$;FOR  THE  LANGUAGE  MODEST. 

e 

6SAVE  MOD. EXE 
MOD. EXE. 3  Saved 

i 

eVDI  MOD. EXE 
PS:<OBJT> 

MOD . EXE . 3 j P77 5200  268  137216(36)  6-Jul-8l  18:02:16  GOGUEN 

6; THUS  FILE  MOD. EXE  IS  IN  DIRECTORY  <OBJT>  ,  268  PAGES  LONG 
«R  MOD 

[CHKPOINT: (7  6  8l)AT(l8  2  10)] 


IN  MOTEST  NI 


•••  TEST  PROGRAMS  FOR  THE  MODEST  DEFINITION  ••• 

•••  FIRST  TESTS  FOR  CONDITIONAL  ••• 

RUN  EXECUTE ((BEGIN  »A  :  INT  ;  READ  'A  ;(IF:  'A  <=  4  THEN 
PRINTC  A  +  1)ELSE  PRINTCA  •  2):FI)END) 
WITH-INPUT (<  INT  :  2  >))  NUR 
AS  TAPE:  (<  INT  :  3  >) 


RUN  EXECUTE ((BEGIN  *A  :  INT  ;  READ  'A  ;(IF:  *A  <=  4  THEN 
PRINTCA  +  1)ELSE  PRINT( 'A  «  2):FI)END) 
WITH-INPUT (<  INT  :  5  >))  NUR 
AS  TAPE:  (<  INT  :  10  >) 


•••  A  TEST  FOR  WHILE  ••• 

RUN  EXECUTE ((BEGIN  'A  :  INT  ;  'S  :  INT  ;  READ  'A  ;  'S  := 
0  ;  WHILECA  >  0)D0(*S  :  =  (  *  A  +  'S);  'A  :  =  ( 
'A  -  1);  PRINT  'S)OD  END)WITH-INPUT(<  INT  : 
2  >))  NUR 

AS  TAPE:  ((<  INT  :  2  >);(<  INT  :  3  >)) 


«**  A  TEST  FOR  BLOCKS  *** 

RUN  EXECUTE( (BEGIN  'A  :  INT  ;  'B  :  INT  ; (READ  'A  ;  'B  :=( 
'A  +  11);  PRINT  'B); (BEGIN  *A  :  INT  ;  READ 
•A  ;  ’B  :  =  C  A  +  5);  PRINT  ’B  END);  'B  :=('A 
+  22);  PRINT  'B  END) WITH-INPUT (<  INT  :  11 
>  ;  <  INT  :  5  >))  NUR 

AS  TAPE:  ((<  INT  :  22  >);(<  INT  :  10  >);(<  INT  :  33  >)) 


•••  TESTS  FOR  RECURSION .FIRST  FACTORIAL  ••• 

RUN  EXECUTE ((BEGIN  'S  :  INT  ;  'M  :  INT  ;  PROC  'P  [  'A  : 

INT  ]('S  :=('S  •  ' A))END  ;  ’S  :=  1  ;  READ 
•M  ;  WHILE ( 'M  >  1 ) DO (CALL  'P  [  'M  ]  ;  'M  := 
CM  -  1 )  )OD  ;  PRINT  'S  END)WITH-INPUT(<  INT 
:  2  >))  NUR 

AS  TAPE:  (<  INT  :  2  >) 


RUN  EXECUTE (( BEGIN C A  :  INT  ; (PROC  *P  [  *B  :  INT  3 (IF: ( *B 
<=  3)THEN(CALL  'P  [  ’B  +  1  ])ELSE(PRINTCB 
♦  11)) :FI)END) ) ; (READ  'A  ;  CALL  'P  [  'A  ]) 
END )WITH-INPUT  <  INT  :  1  >)  NUR 
AS  TAPE:  (<  INT  :  15  >) 


•••  TESTS  FOR  PROCEDURES  AS  PARAMETERS  ••• 

RUN  EXECUTE ((BEGIN (’A  :  INT  ;  *Q  :  PROC[  INT  ]  ; (PROC  'S 
[  'C  :  INT  ] (PRINT  »C)END) ; (PROC  'P  [  *R  : 
PROCL  INT  ]  ;  'D  :  INT  ](CALL  *R  [  ’D  ])END 
)) ; (READ  'A  ;  'Q  :*  *S  ;(CALL  *P  [  *Q  ;  'A 
]) )END) WITH-INPUT (<  INT  :  22  >))  NUR 
AS  TAPE:  (<  INT  :  22  >) 


RUN  EXECUTE ( ( BEGIN ( ' A  :  INT  ;  'Q  :  PROC[(PROC[  INT  ]  ; 

INT  ;  INT)]  ; (PROC  *P  [('R  :  PROCt  INT  ]  ; 
*B  :  INT  ;  »C  :  INT)](CALL  *R  C('B  ♦  *0  3 ) 
END) ; (PROC  'S  [  'A  :  INT  ](PRINT(»A  ♦  11)) 
END) ) ; ( * Q  :=  'P  ;  READ  'A  ;(CALL  'Q  [  ’S  ; 
'A  ;  'A  ]))END) WITH-INPUT (<  INT  :  11  >)) 
NUR 

AS  TAPE:  (<  INT  :  33  >) 


=End  of  files 
EXIT 

e 

«POP 

[PHOTO:  Recording  terminated  Mon  6-Jul-8l  6:18PM] 


32 


C  STMBOLTREE  SPECIFICATION 


[PHOTO:  Recording  initiated  Tue  9-Dec-80  11:32PH] 

Link  from  OBJT,  TTY  31 

TOPS-20  Command  processor  3A(30)-3 
eOBJT 

•••OBJT  12/2/79 

IN  NAT  POBJS  INDEX  TREE  STREE  NI 

•••  NAT. OBJ  :  DEFINES  NATURAL  NUMBER  FROM  INTEGER  USING 
CONSTRUCTOR  OPERATION  (  #  N  )  AND  ERROR  CONDITION  (  N  <  0 

)  see 

OBJ  NAT  /  INT 
SORTS  NAT 
OK-OPS 

#_  :  INT  ->  NAT 
INC  :  NAT  ->  NAT 
DEC  :  NAT  ->  NAT 
POS  :  NAT  ->  BOOL 
ERR-OPS 

NEG  :  ->  NAT 

VARS 

N  :  INT 

EQNS 

(DEC(#  N)=  #  DEC(N) ) 

OK -EQNS 

(INC(#  N)=  #  INC(N) ) 

(POS(#  N)=  N  >  0) 

ERR-EQNS 

(#  N  =  NEG  IF  N  <  0) 

JBO 


•••  TEST  CASES  FOR  NAT  ••» 
RUN  INC(INC(#  *0)  NUR 
AS  NAT:  (#  6) 


RUN  DEC(DEC(*  1))  NUR 
AS  NAT:  »ERROR»  NEG 


RUN  INC(DEC(DEC(#  1)))  NUR 
AS  NAT:  »ERROR»  INC(NEG) 


RUN  DEC(DEC(DEC(*  1)))  NUR 


33 


AS  NAT:  »ERROR»  DEC(NEG) 


RUN  DEC(INC(DEC(#  1)))  NUR 
AS  NAT:  (#  0) 

=End  of  file= 

•••  POBJS. OBJ  :  DEFINES  PARAMETERIZED  OBJECTS  ARRAY  AND 
PAIR  «* 

OBJ  ARRAY  /  BOOL 

SORTS  ARRAY  INDEX  ELEM  /  BOOL 

OK-OPS 

NILARRAY  :  ->  ARRAY 
PUT  :  INDEX  ELEM  ARRAY  ->  ARRAY 
_[_]  :  ARRAY  INDEX  ->  ELEM 
_IN__  :  INDEX  ARRAY  ->  BOOL 
ERR-OPS 

UNDEF  :  INDEX  ->  ELEM 

VARS 

A  :  ARRAY 
II':  INDEX 
V  V  :  ELEM 
OK-EQNS 

(PUT(I,V,A)[  I'  ]  =  V  IF  I  ==  I') 

(=  A  [  I'  ]  IF  NOT  I  h  I') 

(I  IN  NILARRAY  =  F) 

(I  IN  PUT(I',V,A)=  I  ==  I'  OR  I  IN  A) 

ERR-EQNS 

(A  [  I  ]  a  UNDEF(I)IF  NOT  I  IN  A) 

JBO 


OBJ  PAIR 

SORTS  PAIR  Cl  C2 

OK-OPS 

:  Cl  C2  ->  PAIR 
#1_  :  PAIR  ->  Cl 

#2_  :  PAIR  ->  C2 

VARS 

Cl  :  Cl 
C2  :  C2 
P  :  PAIR 
OK-EQNS 

(#1  <  Cl  ;  C2  >  =  Cl) 

(#2  <  Cl  ;  C2  >  =  C2) 

(<  #1  P  ;  #2  P  >  =  P) 

JBO 


=End  of  filer 


3M 


•••  INDEX. OBJ  :  DEFINES  INDEX  =  POINTER  TO  A  NODE  IN  A 
TREE  •« 

OBJ  INDEX  /  NAT 
SORTS  INDEX 
OK-OPS 

INDEX  :  ->  INDEX 
POP_  :  INDEX  ->  INDEX 
:  INDEX  NAT  ->  INDEX 
NEXT_  :  INDEX  ->  INDEX 
PREV_  :  INDEX  ->  INDEX 
ERR-OPS 

UNDEF  :  ->  INDEX 
NO-PREV  :  ->  INDEX 
VARS 

P  :  INDEX 
N  :  NAT 
OK-EQNS 

(POP(P  .  N)=  P) 

(NEXT(P  .  N)=  P  .  INC(N) ) 

(PREV(P  .  N)=  P  .  DEC(N) ) 

ERR-EQNS 

(POP  INDEX  =  UNDEF) 

(P  .  N  =  NO-PREV  IF  ERR(N) ) 

J  BO 


•••  TEST  CASES  FOR  INDEX 
OBJ  INDEXTEST  /  INDEX 
OK-OPS 

PI  :  ->  INDEX 

EQNS 

(PI  =  INDEX  .  #  1  .  #  2  .  #  3) 

JBO 


RUN  PI  NUR 

AS  INDEX:  (((INDEX  .(#  1)).(#  2 )).(#  3)) 


RUN  POP  PI  NUR 

AS  INDEX:  ((INDEX  .(#  1)).(#  2)) 


RUN  POP  POP  PI  NUR 
AS  INDEX:  (INDEX  .(#  1}) 


RUN  POP  POP  POP  PI  NUR 
AS  INDEX:  INDEX 


RUN  POP  POP  POP  POP  PI  NUR 
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AS  INDEX:  »ERROR»  UNDEF 


RUN  NEXT  PI  NUR 

AS  INDEX:  (((INDEX  .(#  1)).(#  2)).(#  4)) 


RUN  PREV  PI  NUR 

AS  INDEX:  (((INDEX  .(#  1)).(#  2)).(#  2)) 


=End  of  file= 


TREE. OBJ  :  DEFINES  LABELED  TREE  AS  INDEXED  ARRAY  , 
WITH  LABEL  AS  A  PARAMETER  ••• 

IM  (ARRAY  =>  LTREE1 )/  INDEX 
SORTS  (ARRAY  =>  LTREE) 

(ELEM  =>  LABEL) 

OPS  (NILARRAY  :  ->  ARRAY  =>  NILTREE) 

MI 


OBJ  LTREE  /  LTREE 1 
OK-OPS 

ARITY  :  INDEX  LTREE  ->  INT 
BREADTH  :  INDEX  LTREE  ->  INT 
FIRST  :  INDEX  LTREE  ->  INDEX 
LAST  :  INDEX  LTREE  ->  INDEX 
PUSH  :  INDEX  LTREE  ->  INDEX 
PUSH  :  INDEX  LABEL  LTREE  ->  LTREE 
ERR-OPS 

BAD-INDEX  :  ->  INT 
BAD-INDEX  :  INDEX  ->  INDEX 
BAD-INDEX  :  INDEX  ->  LTREE 

VARS 

T  :  LTREE 
P  :  INDEX 
N  :  NAT 
L  :  LABEL 
I  :  INT 
OK-EQNS 

( BREADTH (P  .  #  1,T)=  0  IF  NOT(P  .  #  1 )IN  T) 

( BREADTH (P  .  N,T)=  BREADTH (P  .  INC(N) ,T)IF(P  . 
INC(N ) )IN  T) 

( BREADTH (P  .  #  I,T)=  I  IF(P  .  #  I)IN  T  AND  NOT(P 
.  #  INC(I ) )IN  T) 

(FIRST(P,T)=  P  .  #  1  IF(P  .  #  DIN  T) 
(ARITY(P,T)=  BREADTH(P  .  #  1,T)) 

(LAST(P,T)=  P  .  #  ARITY(P,T) ) 

(PUSH(P,T)=  P  •  #  INC( ARITY(P, T) ) ) 


36 


(PUSH(P,L,T)=  PUT(PUSH(P,T),L,T)IF  P  IN  T) 

ERR -EONS 

( BREADTH (P  .  #  0,T)  =  BAD-INDEX) 

( BREADTH (P  .  N,T)  =  BAD-INDEX  IF  NOT  P  IN  T  OR 
ERR(N)) 

(FIRST(P,T)=  BAD-INDEX(P)IF  NOT(P  .  #  1 )XN  T) 
(LAST(P,T)=  BAD-INDEX ( P ) IF  NOT(P  .  #  ARITY(P ,T) ) 
IN  T) 

(PUSH(P,L,T)=  BAD-INDEX(P)IF  NOT  P  IN  T) 

JBO 


•••  INSTANTIATE  LABEL  TO  INTEGER  IN  LTREE  AND  TEST  •« 

IM  (LTREE  =>  INTREE)/  INDEX 
SORTS  (LABEL  =>  INT) 

MI 


OBJ  LTREETEST  /  INTREE 
OK-OPS 

P_  :  INT  ->  INDEX 
T_  :  INT  ->  LTREE 

EQNS 

(P  0  =  INDEX) 

(T  0  =  PUT(P  0,0,NILTREE) ) 
(P  1  =  P  0  .  #  1) 

(T  1  =  PUT(P  1,1, T  0)) 

(P  2  =  NEXT  P  1) 

(T2:  PUT(P  2,2, T  1)) 

(P  3  =  p  2  .  #  1) 

(T  3  =  PUT(P  3,3,T  2)) 

(P  4  =  NEXT  P  3) 

(T  4  =  PUT(P  4,4,T  3)) 

(P  5  =  NEXT  P  4) 

(T  5  =  PUT(P  5,5,T  4)) 

(T  6  =  PUSH(P  0,6,T  5)) 

(P  6  =  PUSH(P  0,T  5)) 

(T  7  =  PUSH(P  2,7 ,T  5)) 

(P  7  =  PUSH(P  2,T  5)) 

(T  8  =  PUSH(P  3.8, T  5)) 

(P  8  =  PUSH(P  3,T  5)) 

(T  9  =  PUSH(P  5,9,T  5)) 

(P  9  =  PUSH(P  5,T  5)) 

JBO 


RUN  ARITY(P  0,T  5)  NUR 
AS  INT:  2 


RUN  ARITY(P  2,T  5)  NUR 
AS  INT:  3 
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(PUSH(P,L,T)=  PUT(PUSH(P,T) ,L,T)IF  P  IN  T) 
ERR-EQNS 

( BREADTH (P  .  #  0,T)=  BAD-INDEX) 

( BREADTH (P  .  N,T)  =  BAD-INDEX  IP  NOT  P  IN  T  OR 
ERR(N) ) 

(FIRST(P,T)=  BAD-INDEX(P )IF  NOT(P  .  #  1 )IN  T) 
(LAST(P,T)=  BAD-INDEX ( P ) IF  NOT(P  .  #  ARITY(P ,T) ) 
IN  T) 

(PUSH(P,L,T)=  BAD-INDEX (P) IF  NOT  P  IN  T) 

JBO 


»»*  INSTANTIATE  LABEL  TO  INTEGER  IN  LTREE  AND  TEST  ••• 

IM  (LTREE  =>  INTREE)/  INDEX 
SORTS  (LABEL  =>  INT) 

MI 


OBJ  LTREETEST  /  INTREE 
OK-OPS 

P_  :  INT  ->  INDEX 
T_  :  INT  ->  LTREE 
EQNS 

(P  0  =  INDEX) 

(T  0  =  PUT(P  0,0,NILTREE) ) 
(P  1  =  P  0  .  #  1) 

(T  1  =  PUT(P  1, 1 ,T  0)) 

(P  2  =  NEXT  P  1) 

(T  2  =  PUT(P  2,2, T  1)) 

(P  3  =  P  2  .  #  1) 

(T  3  =  PUT(P  3»3,T  2)) 

(P  4  :  NEXT  P  3) 

(T  4  =  PUT(P  4,4,T  3)) 

(P  5  =  NEXT  P  4) 

(T  5  =  PUT(P  5,5,T  4)) 

(T  6  =  PUSH(P  0,6,T  5)) 

(P  6  =  PUSH(P  0, T  5)) 

(T  7  =  PUSH(P  2,7 ,1  5)) 

(P  7  =  PUSH(P  2,T  5)) 

(T  8  =  PUSH(P  3,8,T  5)) 

(P  8  =  PUSH(P  3»T  5)) 

(T  9  =  PUSH(P  5,9,T  5)) 

(P  9  =  PUSH(P  5, T  5)) 

JBO 


RUN  ARITY(P  0,T  5)  NUR 
AS  INT:  2 


RUN  ARITY(P  2,T  5)  NUR 
AS  INT:  3 
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RUN  ARITY(P  3 
AS  INT:  0 


RUN  ARITY(P  4 
AS  INT:  0 


RUN  ARITY(P  5 
AS  INT:  0 


RUN  T  5  t  P  0 
AS  INT:  0 


RUN  T  5  [  P  1 
AS  INT:  1 


RUN  T  5  [  P  2 
AS  INT:  2 


RUN  T  5  [  P  3 
AS  INT:  3 


RUN  T  5  [  P  4 
AS  INT:  4 


RUN  T  5  t  P  5 
AS  INT:  5 


RUN  T  9  [  P  0 
AS  INT:  0 


RUN  T  9  [  P  1 
AS  INT:  1 


RUN  T  9  [  P  2 
AS  INT:  2 


RUN  T  9  [  P  3 
AS  INT:  3 


T  5)  NUR 

T  5)  NUR 

T  5)  NUR 

]  NUR 

]  NUR 

]  NUR 

]  NUR 

]  NUR 

]  NUR 

]  NUR 

]  NUR 

]  NUR 

]  NUR 
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RUN  T  9  [  P  4  ]  NUR 
AS  INT:  4 


RUN  T  9  [  P  5  ]  NUR 
AS  INT:  5 


RUN  T  9  [  P  6  ]  NUR 

AS  INT:  »ERROR»  UNDEF( (INDEX  .(#  3))) 


RUN  T  9  t  P  7  3  NUR 

AS  INT:  »ERROR»  UNDEF( ( (INDEX  .(#  2)).(#  4))) 


RUN  T  9  [  P  8  ]  NUR 

AS  INT:  »ERROR»  UNDEF( (( (INDEX  .(#  2)).(#  1)).(#  D)) 


RUN  T  9  t  P  9  ]  NUR 
AS  INT:  9 


=End  of  files 


•••  STREE . OBJ  :  DEFINES  SYMBOLTREE  ,  PARAMETERIZED  BY 
LABEL  «» 


IM  (PAIR  s>  STREE D/  LTREE 
SORTS  (PAIR  =>  STREE) 

(Cl  s>  INDEX) 

(C 2  =>  LTREE) 

MI 


OBJ  STREE  /  STREE 1 
OK-OPS 

NILSTREE  :  ->  STREE 
PUSH  :  STREE  LABEL  ->  STREE 
LABEL  :  STREE  LABEL  ->  STREE 
VAU_  :  STREE  ->  LABEL 
POP_  :  STREE  ->  STREE 
NEXT_  :  STREE  ->  STREE 
PREV_  :  STREE  ->  STREE 

VARS 

ST  :  STREE 
L  :  LABEL 
OK-EQHS 

(NILSTREE  =  <  INDEX  ;  NILTREE  >) 

(PUSH(ST.L)s  <  §\  ST  .  #  INC(ARITY(#1  ST, #2  ST)) 
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;  PUSH(#1  ST,L,#2  ST)>) 

(LABEL(ST,L)=  <  #1  ST  ;  PUT(#1  ST,L,#2  ST)>) 
(VAL  ST  =  #2  ST  [  #1  ST  ]) 

(POP  ST  =  <  POP  #1  ST  ;  #2  ST  >) 

(NEXT  ST  =  <  NEXT  #1  ST  ;  #2  ST  >) 

(PREV  ST  =  <  PREV  #1  ST  ;  #2  ST  >) 

JBO 


«•  INSTANTIATE  LABEL  TO  INT  AND  TEST  ••• 

IM  (STREE  s>  INTSTREE)/  STREE1 
SORTS  (LABEL  =>  INT) 

MI 


OBJ  STREETEST  /  INTSTREE 
OK-OPS 

T_  :  INT  ->  STREE 

EQNS 

(TO:  LABEL(NILSTREE.O)) 
(T  1  =  PUSH(T  0,1)) 

(T  2  =  PUSH (POP  T  1,2)) 

(T  3  »  PUSH (POP  T  2,3)) 

(T  4  =  PUSH(POP  T  3,4)) 

(I  5  s  PUSH(T  4,5)) 

(T  6  =  PUSH (POP  T  5,6)) 

(T  7  =  POP  T  6) 

JBO 


RUN  VAL  T  0  NUR 
AS  INT:  0 


RUN  VAL  T  1  NUR 
AS  INT:  1 


RUN  VAL  T  2  NUR 
AS  INT:  2 


RUN  VAL  T  3  NUR 
AS  INT:  3 


RUN  VAL  T  4  NUR 
AS  INT:  4 


RUN  VAL  T  5  NUR 
AS  INT:  5 
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RUN  VAL  T  6  NUR 
AS  INT:  6 


RUN  VAL  T  7  NUR 
AS  INT:  4 


RUN  VAL  PREV  T  7  NUR 
AS  INT:  3 


RUN  VAL  PREV  T  6  NUR 
AS  INT:  5 


RUN  VAL  PREV  T  4  NUR 
AS  INT:  3 


=End  of  file= 


> 

> 

EXIT 

e 


gPOP 

[PHOTO:  Recording  terminated  Tue  9-Dec-80  11:45PM] 
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D  SPECIFICATION  OF  GRAPHS  AND  PATHS 


[PHOTO:  Recording  initiated  Mon  6-Jul-8l  5:04PM] 
Link  from  GOGUEN,  TTY  10 
T0PS-20  Command  processor  3A( 37 )— 3 
N0BJT20 

•**0BJT  4/17/81 


> 

IN  GRAPH  NI 

0BJT20  Running  at  404602  Load  2.23  Used  0:02:25.8  in  0:34:03 


•••  DEFINITIONS  OF  GRAPH  AND  PATH, TO  BE  LATER  SPECIALIZED 
TO  PARTICULAR  GRAPHS  ••• 


OBJ  GRAPH 
SORTS  NODE  ARC 
OK-OPS 

BEGIN_  :  ARC  ->  NODE 
END__  :  ARC  ->  NODE 

JBO 


OBJ  PATH  /  GRAPH  BOOL 

SORTS  PATH 

OK-OPS 

SOURCE-  :  PATH  ->  NODE 
TARGET-  :  PATH  ->  NODE 
NIL  :  NODE  ->  PATH 
APPEND  :  PATH  ARC  ->  PATH 
ERR-OPS 

ERRORPATH  :  NODE  NODE  ->  PATH 

VARS 

N  N*  :  NODE 
P  :  PATH 
A  :  ARC 
OK-EQNS 

(SOURCE  NIL(N)s  N) 

(TARGET  NIL(N):  N) 

(SOURCE  APPEND(P, A)s  SOURCE  P) 

(TARGET  APPEND(P, A)*  END  A) 

ERR-EQNS 

(APPEND(P.A)*  ERRORPATH (SOURCE  P,END  A)IF  NOT 
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TARGET  P  ==  BEGIN  A) 
JBO 


OBJ  GRAPH 1  /  PATH 


OK-OPS 

N1 

->  NODE 

N2 

->  NODE 

N3 

->  NODE 

N4 

->  NODE 

At 

->  ARC 

A2 

->  ARC 

A3 

->  ARC 

OK-EQNS 

(BEGIN  A1  s  N1) 
(BEGIN  A2  3  N2) 
(BEGIN  A3  =  N4) 
(END  A1  3  N 2) 
(END  A2  3  N3) 
(END  A3  =  N3) 

JBO 


•••  NOW  SOME  TEST  CASES  »» 

RUN  APPEND(NIL(N1),A1)  NUR 
AS  PATH:  APPEND(NIL(N1) ,A1) 


RUN  APPEND(APPEND(NIL(N1),A1),A2)  NUR 
AS  PATH:  APPEND( APPEND (NIL (Nt) ,A1) ,A2) 


RUN  APPEND(APPEND(APPEND(NIL(N1),A1),A2),A3)  NUR 
AS  PATH:  »ERROR»  ERRORPATH(N1  ,N3) 


RUN  APPEND(NIL(N1) ,A2)  NUR 
AS  PATH:  »ERROR»  ERRORPATH(N1 ,N3) 


RUN  APPEND(APPEND(NIL(N1),A1),A3)  NUR 
AS  PATH:  »ERROR»  ERROR  PATH  (N 1 , N3 ) 


•••  WE  NOW  DEFINE  ANOTHER  GRAPH  *«• 


OBJ  GRAPH2  /  PATH 
OK-OPS 


N1 

->  NODE 

N2 

->  NODE 

N3 

->  NODE 

N4 

->  NODE 

A1 

->  ARC 

A2 

->  ARC 

A3 

->  ARC 

A4 

->  ARC 

OK-EQNS 

(BEGIN  A1  a  N2) 
(BEGIN  A 2  a  N2) 
(BEGIN  A3  =  N3) 
(BEGIN  A3  =  N1) 
(END  A1  a  N1) 
(END  A2  a  N3) 
(END  A3  =  N4) 
(END  A3  =  N4) 
(END  A4  a  N1) 

JBO 


•••  NOW  SOME  TEST  CASES  FOR  THE  SECOND  GRAPH  ••• 

RUN  APPEND(NIL(N1) ,A1)  NUR 
AS  PATH:  »ERROR»  ERRORPATH(N  1  ,N1 ) 


RUN  APPEND (NIL (N2) , A 1 )  NUR 
AS  PATH:  APPEND(NIL(N2) , A1 ) 


RUN  APPEND ( APPEND ( NIL (N 1 ) ,A1 ) , A2)  NUR 

AS  PATH:  »ERROR»  ERRORPATH( (SOURCE  ERRORPATH(N1 ,N1 ) ) ,N3 

) 


RUN  APPEND (APPEND (NIL (N2) ,A1 ) , A4)  NUR 
AS  PATH:  »ERROR»  ERRORPATH(N2,N1 ) 


RUN  APPEND(APPEND(APPEND(NIL(N2),A1),A4),A3)  NUR 
AS  PATH:  »ERROR»  ERRORPATH( (SOURCE  ERR0RPATH(N2,N1 ) ) ,N4 
) 


RUN  APPEND (NIL (N1),A2)  NUR 
AS  PATH:  »ERROR»  ERRORPATH(N1  ,N3) 


RUN  APPEND (APPEND (NIL (N1),A4), A3)  NUR 

AS  PATH:  »ERROR»  ERROR  PATH  { (SOURCE  ERRORPATH(N1  ,N1 ) )  ,NM 

) 


sEnd  of  file= 

> 

EXIT 

% 

«POP 

[PHOTO:  Recording  terminated  Mon  6-Jul-8i  5:05PM] 
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E  TECHNIQUES  FOR  HIGHER  ORDEB  SPECIFICATIONS  AND  OTHER  SURPRISES 


HERE  ARE  SOME  INTERESTING  THINGS  YOU  MIGHT  NOT  HAVE  REALIZED 
COULD  BE  DONE  WITH  OBJT:  DEFINE  THE  NATURALS  FROM  THE  INTEGERS; 
GET  THE  EFFECT  OF  HIGHER  ORDER  PARAMETERIZED  TYPES;  AND  DEFINE 
PARAMETERIZED  TYPES  WHICH  DO  NOT  PRESERVE  THEIR  ARGUMENT  OBJECTS, 
BUT  RATHER  DIVIDE  THEM  BY  5. 


[PHOTO:  Recording  Initiated  Tue  9-Dec-80  11:32PM] 

Link  from  OBJT,  TTY  31 

TOPS-20  Command  processor  3A(30)-3 
gOBJT 

•••OBJT  12/2/79 

IN  NAT  POBJS  INDEX  TREE  STREE  NI 

•••  NAT. OBJ  :  DEFINES  NATURAL  NUMBER  FROM  INTEGER  USING 
CONSTRUCTOR  OPERATION  (  #  N  )  AND  ERROR  CONDITION  (  N  <  0 

)  ••• 

OBJ  NAT  /  INT 
SORTS  NAT 
OK-OPS 

#_  :  INT  ->  NAT 
INC  :  NAT  ->  NAT 

DEC  :  NAT  ->  NAT 

POS  :  NAT  ->  BOOL 

ERR-OPS 

NEG  :  ->  NAT 

VARS 

N  :  INT 

EQNS 

( DEC ( #  N)=  #  DEC(N)) 

OK -EQNS 

(INC(#  N)=  #  INC(N)) 

(POS(#  N)=  N  >  0) 

ERR-EQNS 

(f  N  =  NEG  IF  N  <  0) 

JBO 


•••  TEST  CASES  FOR  NAT  ••• 
RUN  INC(INC(#  4))  NUR 
AS  NAT:  (*  6) 


RUN  DEC(DEC(#  1))  NUR 


AS  NAT:  »ERROR»  NEG 


RUN  INC(DEC(DEC(#  1)))  NUR 
AS  NAT:  »ERROR»  INC(NEG) 


RUN  DEC(DEC(DEC(#  1)))  NUR 
AS  NAT:  »ERROR»  DEC  (NEG) 


RUN  DEC(INC(DEC(#  1)))  NUR 
AS  NAT:  (#  0) 


=End  of  file= 


[PHOTO:  Recording  initiated  Mon  13-Apr-81  6:57PM] 

Link  from  OBJT,  TTY  1 

T0PS-20  Command  processor  3A(32)-3 
End  of  COMAND.CMD. 1 
90BJT 


•••OBJT  12/2/79 


>IN  MAPLST.OBJ  NI 


•••  MAPLIST  AS  PARAMETERIZED  OBJECT  ••• 
OBJ  MAPLIST 
SORTS  E  L 
OK-OPS 

_  :  E  ->  L 
NIL  :  ->  L 

:  L  L  ->  L  (ASSOCIATIVE) 

FE  :  E  ->  E 
FL  :  L  ->  L 
VARS 

LL'  :  L 
E  :  E 
OK-EQNS 

(NIL  .  L  =  L) 

(L  .  NIL  =  L) 

(FL(E)s  FE(E)) 

(FL(NIL)s  NIL) 

(FL(E  .  L)  =  FE(E).  FL(L) ) 

JBO 
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•••  WE  NOW  INSTANTIATE  IT  TO  A  SQUARING  FUNCTION  ON  LISTS 
,  BUT  MUST  FIRST  DEFINE  THE  SQUARING  FUNCTION  ••• 

OBJ  INTSQ  /  INT 
OK-OPS 

SQ  :  INT  ->  INT 

VARS 

N  :  INT 
OK-EQNS 

(SQ(N)s  N  «  N) 

JBO 


IM  (MAPLIST  =>  NATLISTSQ)/  INTSQ 
SORTS  (E  =>  INT) 

(L  =>  INTLIST) 

OPS  (FE  :  E  ->  E  =>  SQ) 

MI 


RUN  FLO  .  2  .  3)  NUR 
AS  INTLIST:  (1  .  4  .  9) 


RUN  FL(3  .  6  .  17)  NUR 
AS  INTLIST:  (9  .  36  .  289) 


WE  NOW  INSTANTIATE  THIS  TO  AN  ADD1  FUNCTION  ON  LISTS 

HI 


IM  (MAPLIST  =>  INTLISTINC)/  INT 
SORTS  (E  =>  INT) 

(L  =>  INTLIST) 

OPS  (FE  :  E  ->  E  =>  INC) 

MI 


RUN  FLO  .2.3)  NUR 
AS  INTLIST:  (2  .  3  .  *0 


RUN  FL(3  .  6  .  17)  NUR 
AS  INTLIST:  (4.7.  18) 


=End  of  files 

>EXIT 

«POP 

[PHOTO:  Recording  terminated  Mon  13-Apr-8l  6:58PM] 
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[PHOTO:  Recording  initiated  Mon  13-Apr-8l 

Link  from  OBJT,  TTY  1 

T0PS-20  Command  processor  3A(32)-3 
End  of  COMAND.CMD. 1 
60BJT 

•••OBJT  12/2/79 

>IN  NAT5  NI 


•••  NATURAL  NUMBERS  ••• 

OBJ  NAT 
SORTS  N 
OK-OPS 

Z  :  ->  N 
S  :  N  ->  N 

:  N  N  ->  N 

VARS 

M  P  :  N 
OK-EQNS 

(Z  +  M  =  M) 

(S(M)+  P  =  S(M  +  P)) 
JBO 


RUN  Z  NUR 
AS  N:  Z 


RUN  S(Z)  NUR 
AS  N:  S(Z) 


RUN  S(S(Z))  NUR 
AS  N:  S(S(Z)) 


RUN  S(S(S(Z)))  NUR 
AS  N:  S(S(S(Z))) 


RUN  S(S(S(S(S(Z)))))  NUR 
AS  N:  S(S(S(S(S(Z))))) 


RUN  S(S(S(S(S(S(Z))))))  NUR 


7:04PM] 


49 


AS  N:  S(S(S(S(S(S(Z)))))) 


RUN  S(S(S(S(S(S(S(Z)))))))  NUR 
AS  N:  S(S(S(S(S(S(S(Z))))))) 


RUN  S(S(S(S(S(S(S(S(Z))))))))  NUR 
AS  N:  S(S(S(S(S(S(S(S(Z)))))))) 


RUN  S(S(S(S(S(S(S(S(Z))))))))  NUR 
AS  N:  S(S(S(S(S(S(S(S(Z)))))))) 


RUN  S(S(Z))+  S(S(Z))  NUR 
AS  N:  S(S(S(S(Z)))) 


RUN  S(S(Z))+  S(S(S(Z)))  NUR 
AS  N:  S(S(S(S(S(Z))))) 


•••  THIS  PARAMETERIZED  OBJECT  IDENTIFIES  5  AND  0  »• 
OBJ  MODS 
SORTS  N 
OK-OPS 

Z  :  ->  N 
S  :  N  ->  N 

VARS 

N  :  N 
OK-EQNS 

(S(S(S(S(S(Z)))))=  Z) 

JBO 


WE  NOW  INSTANTIATE  IT  TO  THE  NATURALS  AS  ABOVE  ••• 

IM  (MOD5  =>  NAT5) 

SORTS  (N  =>  NAT) 

MI 


RUN  Z  NUR 
AS  NAT:  Z 


RUN  S(Z)  NUR 
AS  NAT:  S(Z) 


RUN  S(S(Z})  NUR 


AS  NAT:  S(S(Z)) 


RUN  S(S(S( Z)))  NUR 
AS  NAT:  S(S(S(Z))) 


RUN  S(S(S(S(S(Z)))))  NUR 
AS  NAT:  Z 


RUN  S(S(S(S(S(S(Z))))))  NUR 
AS  NAT:  S(Z) 


RUN  S(S(S(S(S(S(S(Z)))))))  NUR 
AS  NAT:  S(S(Z)) 


RUN  S(S(S(S(S(S(S(S(Z))))))))  NUR 
AS  NAT:  S(S(S(Z))) 


RUN  S(S(S(S(S(S(S(S(Z))))))))  NUR 
AS  NAT:  S(S(S(Z))) 


RUN  S(S(Z))+  S(S(Z))  NUR 

? Warning:  EXPRESSION  CANNOT  BE  PARSED 
RUN  S(S(Z))+  S(S(S(Z)))  NUR 

?Warning:  EXPRESSION  CANNOT  BE  PARSED 

«*  WHAT  HAPPENS  IF  WE  TRY  IT  ON  INT? 

IM  (MOD5  =>  INT5) 

SORTS  (N  =>  INT) 

MI 


RUN  Z  NUR 
AS  INT:  Z 


RUN  S(Z)  NUR 
AS  INT:  S(Z) 


RUN  S(S(Z))  NUR 
AS  INT:  S(S(Z)) 


RUN  S(S(S(Z)))  NUR 
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AS  INT:  S(S(S(Z))) 


RUN  S(S(S(S(S(Z)))))  NUR 
AS  INT:  Z 


RUN  S(S(S(S(S(S(Z))))))  NUR 
AS  INT:  S(Z) 


RUN  S(S(S(S(S(S(S(Z)))))))  NUR 
AS  INT:  S(S(Z)) 


RUN  S(S(S(S(S(S(S(S(Z))))))))  NUR 
AS  INT:  S(S(S(Z))) 


RUN  S(S(S(S(S(S(S(S(Z))))))))  NUR 
AS  INT:  S(S(S(Z))) 


RUN  S(S(Z))+  S(S(Z))  NUR 

?Warning:  EXPRESSION  CANNOT  BE  PARSED 
RUN  S(S(Z))+  S(S(S(Z)))  NUR 

?Warning :  EXPRESSION  CANNOT  BE  PARSED 

=End  of  files 
>IN  NAT5S  NI 


OBJ  NAT5S  /  INT 
OK-EQNS 

(5  =  0) 

?Warning :  INPUT  ABNORMALLY  TERMINATED 

>EXIT 

8P0P 

[PHOTO:  Recording  terminated  Mon  13-Apr-81  7:05PM] 
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F  PARTIAL  ALGEBRAS  WITH  EQUATIONALLY  DEFINED  DOMAINS 

We  have  investigated  partial  algebras  such  that  the  domains  of  definition  of 
their  operations  can  be  equationally  defined.  These  are  very  close  in  spirit 
to  error  algebras[Goguen  77],  on  which  the  semantics  of  OBJ  is  based;  the  main 
difference  is  that,  for  exceptional  cases,  an  operation  is  Just  not  defined, 
instead  of  producing  an  error  message  as  in  the  case  of  error  algebras. 

Partial  algebras,  with  equationally  defined  domains  of  definition  for  their 
operations  have  a  strong  expressive  power.  Moreover,  they  have  initial 
algebras,  relatively  free  algebras,  and  all  limits  and  colimits.  This 
supports  an  initial  algebra  semantics  and  many  useful  constructions. 


We  shall  illustrate  the  concept  with  two  examples.  The  first  is  a  version  of 
stack  of  integers  as  a  partial  algebra  with  equationally  defined  domains.  We 
give  the  specification  in  an  OBJ-like  style[Goguen  &  Tardo  79],  and  will 

explain  our  notation  below. 

OBJ  STACK  /  INTEGER  BOOL 
SORTS  STACK 

VARS  S:  STACK  N:  INTEGER 
OPS  EMPTY  :  ->  STACK 

ISEMPTY  :  STACK  ->  BOOL 
PUSH  :  INTEGER,  STACK  ->  STACK 

POP  :  STACK  :  S  :  (ISEMPTY(S)  =  FALSE)  ->  INTEGER 
TOP  :  STACK  :  S  :  ( ISEMPTY (S)  =  FALSE)  ~>  INTEGER 
EQNS  ISEMPTY(EMPTY)  =  T 

ISEMPTY ( PUSH ( N , S ) )  =  F 
POP(PUSH(S,N))  =  S 
TOP ( PUSH (S,N))  =  N 

JBO 


The  only  operations  that  are  partial  are  POP  and  TOP.  Both  are  defined 

exactly  on  those  values  of  the  STACK  variable  S  such  that  the  equation 

ISEMPTY(S)  =  FALSE  holds,  this  is  represented  by  the  notation 
POP  :  STACK  :  S  :  ( ISEMPTY (S)  =  FALSE)  ->  INTEGER 

and  similarly  for  TOP. 


our  next  definition  is  the  specification  of  the  data  type  path. 
OBJ  PATH 

SORTS  NODE  PATH 

VARS  ABC:  NODE 

F  G  H  :  PATH 
OPS  ID  :  NODE  ->  PATH 

DOM  :  PATH  ->  NODE 
COD  :  PATH  ->  NODE 

:  PATH  :  G  ,  PATH  :  F  :  (DOM(G)  s  COD(F))  ->  PATH 
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EONS  DOM(ID(A) )  =  A 
COD(ID(A))  =  A 
F  .  ID(A)  =  F 
ID(A)  .  F  =  F 
(F  .  G)  .  H  =  F  .  (G  .  H) 

JBO 

The  only  partial  operation  here  is  the  composition  of  paths  which  is 

defined  exactly  for  those  values  of  the  variables  F,G  such  that  the  equation 
DOM(G)  =  COD(F) 

holds.  (Note  that  the  initial  algebra  of  this  specification  is  empty,  but 
constants  of  types  NODE  and  PATH  can  be  added.  Such  constraints  will  specify 
a  given  graph,  and  then  the  initial  algebra  is  the  algebra  of  paths  on  that 
graph. ) 

In  general,  not  only  equations,  but  also  Horn-like  conditional  equations  are 
allowable.  There  is  a  precise  formal  definition  of  the  concept  of  partial 
algebra  with  equationally  defined  domains  satisfying  a  certain  set  of  Horn 
axioms  which  can  be  given  in  terms  of  "essentially  algebraic  theories"  as 
defined  belowCGabriel  Ulmer  71].  These  generalize  total  algebras,  and  use  the 
algebraic  theory  approach[Lawvere  63].  Algebraic  theories  have  also  been  used 
by[Burstall  &  Goguen  77,  Burstall  A  Goguen  80]  for  the  semantics  of  their 
specification  language  CLEAR. 

Definition  1:  A  small  category  T  is  an  essentially  algebraic  theory  if  T  has 
all  finite  limits  (i.e.  finite  products  and  equalizers).  A  functor  H:  T  ->  T' 
between  two  essentially  algebraic  theories  is  a  morphism  of  essentially 
algebraic  theories  if  and  only  if  it  preserves  limits. 

For  instance,  the  specification  of  the  data  type  PATH  above  corresponds  to  a 
theory  TpATH,  in  which  each  object  is  a  finite  limit  of  the  objects  NODE  and 
PATH.  The  object  COMPOSABLE  (where  the  operation  of  path  composition  is 
defined)  is  the  equalizer 


"l  DOM 

- —  PATH  — 

COMPOSABLE  - -  PATH  x  PATH  PATH 

- PATH  - — 

COD 


and  the  equations  correspond  to  forcing  certain  diagrams  to  commute  in  T. 
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Definition  2:  A  category  B  is  a  category  of  partial  algebras  with 
eauatlonallv  defined  domains  if  and  only  if  B  is  equivalent  to  the  category 
aist  =  lim  Funct(T,Set)  of  (finite)  limit  preserving  functors  from  T  to  the 
category  of  sets,  for  T  some  essentially  algebraic  theory. 

If  S  C  Ob(T)  is  a  set  of  objects  of  T  such  that  any  other  object  is  a  finite 
limit  of  objects  in  S,  we  say  that  S  generates  T.  Then  we  can  define  a 
forgetful  functor  Ug  from  Algj  to  the  category  S-Set  of  S-sorted  sets,  given 
on  objects  by  Ug(A)s  =  A(s),  for  every  s  in  S.  For  example,  S  =  {NODE,  PATH) 
generates  TpAjHi  and  Ug  is  in  this  case  the  functor  sending  each  PATH  data 
type  to  its  NODE  and  PATH  sets. 

Theorem  3:  For  T  an  essentially  algebraic  theory,  Alg^  is  complete  and 
cocomplete  (in  particular  it  has  an  initial  object).  If  S  C  Ob(T)  generates 
T,  then  the  functor  Ug:  Alg^  ->  S-Set  has  a  left  adjoint;  i.e.,  there  are  free 
algebras. 

There  are  also  free  extensions .  For  instance  the  specification 
OBJ  GRAPH 
SORTS  NODE  EDGE 
OPS  DOM  :  EDGE  ->  NODE 
COD  :  EDGE  ->  NODE 

JBO 

has  an  associated  (essentially  algebraic)  theory  TGRAPH  which  can  be  embedded 
in  TpATH,  so  that  the  injection  J:  TpATH  ->  TGRApH  is  a  morphism  of  theories. 
This  induces  a  functor  Uj:  AlgT  ->  AlgT  by  composition  with  J:  A  i->  A.J;  this 
functor  considers  every  PATH-algebra  as  a  GRAPH-algebra  by  forgetting  about 
the  operations  of  composition  and  identity.  Uj  has  a  left  adjoint  Fj,  which 
gives  the  free  extension  of  each  graph  to  its  algebra  of  paths.  In  general  we 
have 

Theorem  4:  Let  H:  T  ->  T'  be  a  morphism  of  theories,  and  let  UH:  Alg^,  -> 

AlgT  be  the  functor  induced  by  composition  with  H.  Then  UH  has  a  left  adjoint. 
Our  ultimate  goal  in  this  area  is  to  extend  the  results  on  rewrite-rules  known 
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for  total  algebras  to  the  case  of  partial  algebras  with  equationally  defined 
domains,  as  a  first  step  toward  further  extending  these  results  to  error 
algebras,  and  in  particular  obtaining  for  error  algebras  the  powerful 
structural  results  mentioned  above.  This  will  provide  theoretical  support  for 
some  of  the  more  experimental  features  of  OBJ. 

Using  results  of [Coate  77]  we  have  isolated  a  deductive  system  for  partial 
algebras  with  equationally  defined  domains  which  is  both  consistent  and 
complete,  and  we  are  in  the  process  of  integrating  a  version  of  that  deductive 
system  with  OBJ-style  specifications  like  those  given  above.  We  also  plan  to 
study  the  relationship  to  the  work  of[Kaphengst  &  Reichel  77,  Reichel  & 

Hupbach  &  Kaphengst  80],  and  to  the  categorical  work  of[Gabriel  Ulmer  71].  We 
believe  that  many  of  their  infinitary  constructions  will  specialize  to  the 
finltary  case,  which  is  important  for  the  semantics  of  partial  algebras  with 
equationally  defined  domains,  and  for  error  algebras. 
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G  STRICT  ERROR  ALGEBRAS  DEFINED  BY  TESTS 

We  assume  familiarity  with  error  algebras [Goguen  77].  For  the  case  of  strict 
error  algebras,  i.e.,  error  algebras  where  all  the  error  elements  reduce  to  an 
error  constant  E,  the  meaning  of  OK  and  ERROR  equations  can  be  captured  as 
ordinary  equations  on  the  whole  algebra  if  we  introduce  a  ternary  operation 
IFE(_,_,_),  such  that  IFE(a,b,c)  equals  b  in  case  a  is  the  error  constant  and 
equals  c  otherwise.  For  example,  if  we  want  the  OK  part  to  satisfy  the  axioms 

of  group  theory  we  can  impose  equations  such  as 
x  .  (x)"1  =  IFE(x,E, 1 ) 

X  .  1  =  X 

which  correspond  to  the  axiom  about  the  inverse  and  neutral  elements 

respectively.  If  we  had  just  imposed 
x  .  x-1  =  1 

as  an  ordinary  equation,  this  would  have  given 
E  =  E  .  E-1  =  1 

and  then  every  element  would  collapse  to  the  error  element,  because 
x  .  1  =  x  .  E  =  E. 

For  any  set  I '  of  OK-equations  and  ERROR  equations  encoded  in  this  form,  we 
have  given  a  free  construction,  which  associates  to  each  strict  error 
Z-algebra  another  one  satisfying  I ' ,  and  having  the  obvious  universal 
property.  We  have  also  proved  that  this  process  is  conservative  in  that,  if 
the  2-operations  restrict  to  the  OK  part,  and  we  only  have  OK-equations,  this 
construction  is  equivalent  to  imposing  first  the  OK  equations  as  ordinary 
equations  on  the  OK  part,  and  then  adding  an  error  element.  The  following  is 
a  summary  of  our  definitions  and  results. 

Definition  1:  A  strict  (error)  set  is  a  pair  (A,E),  where  E  belongs  to  A.  A 
function  f :A  ->  B  between  two  strict  error  sets  is  a  strict  ( error )  function 
if  and  only  if  either: 

1.  IAI  =  ! Bi  =  1; 

2.  iBl  =  1;  or 

3.  none  of  the  above  holds  but  f"^{E}  =  {E}. 

For  an  index  set  S  of  sorts,  an  S-sorted  strict  error  set  is  a  family  {(A_, 

E) ^sCS  °F  strict  error  sets,  and  similarly  an  S-sorted  strict  error  function 
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is  a  family  of  strict  error  functions. 

Definition  2;  For  2  an  S-sorted  signature  of  operations,  a  strict  (error) 
2-alyebra  is  an  S-sorted  strict  error  set  A  =  {(A3,E)}ggs  together  with  a 
2-algebra  structure  on  A  such  that  every  operation  ^  gives  as  result  the 

error  element  of  A^  whenever  one  of  its  operands  is  an  error  element;  i.e., 

(i)  <J(x1 , . . .  ,E, . . .  ,xn)  =  E 

for  E  in  any  place  i ,  for  1  <  i  <  n .  A  strict  (error)  S -homomorphism  is  a 
2-homomorphism  that  is  also  a  strict  error  function. 

Note  that  every  strict  error  2-algebra  can  be  made  into  a  2 jpg-algebra,  for 
2ife  signature  obtained  from  2  by  adding  a  constant  E  for  each  sort  s  in 

S,  and  a  ternary  operation  1FE:  s,t,t  ->  t  for  each  pair  of  sorts  s,  t  in 
S.  Given  a  strict  error  2-algebra,  we  interpret  the  constants  E  as  error 
elements,  and  we  define  lFE(a,b,c)  to  be  equal  to  b  if  A  =  E,  and  to  be  equal 
to  c  otherwise.  With  this  definition  every  strict  error  homomorphism  becomes 
a  2 jpg-homomorphism . 

Theorem  1:  Let  I  *  be  a  set  of  Zjpg  equations,  and  for  every  2 IFg  algebra  A 
let  A/ I'  be  the  quotient  algebra  obtained  from  A  by  imposing  the  equations  in 
I ' .  Then  if  A  is  a  strict  error  2-algebra  A/ | *  is  also  a  strict  error 
2-algebra,  the  canonical  quotient  q:  A  ->  A/I'  is  a  strict  error  homomorphism, 
and  for  any  strict  error  2-homomorphism  f:  A  ->  B  such  that  B  satisfies  I'  as 
a  2 jpg-algebra,  there  exists  a  unique  strict  error  homomorphism  F:A/I'  ->  B 
such  that  F.q  =  f. 

To  each  ordinary  2-algebra  A  we  can  associate  a  strict  error  2-algebra  Ag  by 
adding  a  new  element  E  to  each  sort  As,  and  extending  the  operation  0  in  2  in 
the  obvious  way.  The  following  theorem  shows  that  the  construction  of  Theorem 
1  can  be  seen  as  a  "conservative  extension"  of  the  construction  of  imposing 
ordinary  2-equations  when  only  OK-equatlons  are  imposed. 
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Theorem  2:  Let  A  be  a  set  of  2-equations  such  that,  for  each  equation,  the  1 

set  of  variables  occurring  in  its  right  hand  side  is  contained  in  the  set  of 

variables  occurring  in  its  left  hand  side.  Let  I'  be  the  set  of  2jpg 

equations  obtained  from  those  in  A  as  follows:  for  each  u  =  v  in  A,  if  the 

variables  occurring  in  u  and  v  are  the  same,  u  =  v  belongs  to  I';  otherwise 
u  s  IFE(u,E,v) 

belongs  to  I ' .  Then  for  every  2-algebra  A  there  exists  a  natural  isomorphism 

of  strict  error  2-algebras_ 

(A/A)e  1  UE)/I'. 
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H  MODEL-THEORETIC  CHARACTERIZATION  OP  RELATIONAL  CLASSES  OF  PROGRAM  SCHEME 
INTERPRETATIONS 

Making  operations  and  tests  into  elements  of  a  signature  of  operations  2»  any 
interpretation  of  a  program  scheme  can  be  seen  as  a  continuous  I-algebra, 
i.e.,  as  an  ui-cpo  together  with  a  2-algebra  structure  such  that  the 
operations  preserve  limits  of  ui-chains[Goguen,  Thatcher,  Wagner  &  Wright 
77,  Nivat  75].  For  the  equivalence  problem  of  program  schemes  to  be 
tractable,  it  is  convenient  to  consider  not  all  interpretations,  but  Just 
those  in  a  class  defined  by  some  natural  property. 

One  such  case  of  particular  interest,  because  it  allows  proofs  by  computation 

induction,  is  the  relational  classes,  i.e.,  the  classes  of  algebras  A  such 

that  there  is  some  set  of  pairs  of  finitary  2-expressions  (u,v)  such  that 

u(a1,...,an)  <  v(a1,...an) 

for  every  (al , . . .an)CAn  (where  n  is  the  number  of  distinct  variables  occurring 
in  u  or  v)  fo  each  (u,v).  In  [Meseguer  81]  those  classes  have  been 
characterized  model-theoretically  by  the  following  "Birkhoff-like"  result: 

Theorem  1 :  A  class  of  continuous  2-algebras  is  relational  if  and  only  if  it 

is  closed  under 

(i)  products 

(ii)  (continuous)  full  subalgebras 
(ill)  (continuous)  quotients,  and 
(iv)  algebraic  completions. 
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